From rramphul at ripe.net Mon Oct 1 17:09:44 2012 From: rramphul at ripe.net (Radha Ramphul) Date: Mon, 01 Oct 2012 17:09:44 +0200 Subject: [address-policy-wg] Policy Proposal 2011-05 "Safeguarding future IXPs with IPv4 space" implemented Message-ID: <5069B238.9000705@ripe.net> [Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2011-05, "Safeguarding future IXPs with IPv4 space", has been implemented. The RIPE NCC is now ready to accept requests for IXP IPv4 assignments under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2011-05 The updated "IPv4 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-553 IPv4 and IPv6 IXP assignments will now be evaluated using a common request template. You can access the template through the LIR Portal or online at: http://www.ripe.net/ripe/docs/ripe-564 The supporting notes are available at: http://www.ripe.net/ripe/docs/ripe-565 If you have any questions, please contact. Regards, Radha Ramphul Registration Services RIPE NCC From emadaio at ripe.net Tue Oct 2 16:35:14 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 02 Oct 2012 16:35:14 +0200 Subject: [address-policy-wg] Final RIPE 64 APWG Session Minutes Message-ID: <506AFBA2.6000301@ripe.net> Dear colleagues, The draft minutes of the RIPE 64 Address Policy Working Group session were approved during RIPE 65. The final minutes are online at: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-64 Regards Emilio From ripe-wgs.cs at schiefner.de Tue Oct 2 16:44:56 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 02 Oct 2012 16:44:56 +0200 Subject: [address-policy-wg] DRAFT(?) RIPE 64 APWG Session Minutes In-Reply-To: <506AFBA2.6000301@ripe.net> References: <506AFBA2.6000301@ripe.net> Message-ID: <506AFDE8.9080000@schiefner.de> Hi Emilio, they are still draft, right? Best, Carsten On 02.10.2012 16:35, Madaio wrote: > The draft minutes of the RIPE 64 Address Policy Working Group session > were approved during RIPE 65. The final minutes are online at: > > https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-64 From emadaio at ripe.net Tue Oct 2 16:59:34 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 02 Oct 2012 16:59:34 +0200 Subject: [address-policy-wg] Correction: Final Minutes Re: DRAFT(?) RIPE 64 APWG Session Minutes In-Reply-To: <506AFDE8.9080000@schiefner.de> References: <506AFBA2.6000301@ripe.net> <506AFDE8.9080000@schiefner.de> Message-ID: <506B0156.5090709@ripe.net> Hi Carsten, they were declared final by the APWG co-chairs at the RIPE 65 after community review. Apologies if the initial message was not clear. Regards Emilio On 10/2/12 4:44 PM, Carsten Schiefner wrote: > Hi Emilio, > > they are still draft, right? > > Best, > > Carsten > > On 02.10.2012 16:35, Madaio wrote: >> The draft minutes of the RIPE 64 Address Policy Working Group session >> were approved during RIPE 65. The final minutes are online at: >> >> https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-64 > From ripe-wgs.cs at schiefner.de Tue Oct 2 17:05:46 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 02 Oct 2012 17:05:46 +0200 Subject: [address-policy-wg] Correction: Final Minutes Re: DRAFT(?) RIPE 64 APWG Session Minutes In-Reply-To: <506B0156.5090709@ripe.net> References: <506AFBA2.6000301@ripe.net> <506AFDE8.9080000@schiefner.de> <506B0156.5090709@ripe.net> Message-ID: <506B02CA.90108@schiefner.de> Hi Emilio, all - my sincerest apologies. . I got confused by RIPE 64 and RIPE 65 and the meetings' respective draft and final minutes. Now re-reading Emilio's initial mail to this list again, it is entirely clear in its meaning - and I snet off my mail because of my screwed interpretation. Sorry again, Carsten On 02.10.2012 16:59, Emilio Madaio wrote: > Hi Carsten, > they were declared final by the APWG co-chairs at the RIPE 65 after > community review. > > > Apologies if the initial message was not clear. > > > Regards > Emilio > > > > > On 10/2/12 4:44 PM, Carsten Schiefner wrote: >> Hi Emilio, >> >> they are still draft, right? >> >> Best, >> >> Carsten >> >> On 02.10.2012 16:35, Madaio wrote: >>> The draft minutes of the RIPE 64 Address Policy Working Group session >>> were approved during RIPE 65. The final minutes are online at: >>> >>> https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-64 >> From tore.anderson at redpill-linpro.com Wed Oct 3 08:19:41 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 03 Oct 2012 08:19:41 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1349211282.729444.130178216.241366.2@otrs.hostingconsult.ru> References: <50644B56.8070805@redpill-linpro.com><1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349211282.729444.130178216.241366.2@otrs.hostingconsult.ru> Message-ID: <506BD8FD.2040409@redpill-linpro.com> Good morning, * LeaderTelecom B.V. >> So there will not be any requirement whatsoever on the receiving ISP to >> justify their need for the received block, in the way they would have if >> they had gone through a full transfer instead? > > Correct. Why not? I question the wisdom of abolishing the need-based mechanism for sub-allocations exclusively, when (to the best of my knowledge) all other mechanisms to obtain number resources in all other regions are need-based. > Just see how many transfers in other RIRs. This mechanism work not very good > for now. How come? In any case, if the transfer policy is broken somehow, why not fix it? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From info at leadertelecom.nl Tue Oct 2 22:54:42 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Wed, 3 Oct 2012 00:54:42 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <50644B56.8070805@redpill-linpro.com> References: <50644B56.8070805@redpill-linpro.com><1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> Message-ID: <1349211282.729444.130178216.241366.2@otrs.hostingconsult.ru> Dear?Tore, >?So there will not be any requirement whatsoever on the receiving ISP to > justify their need for the received block, in the way they would have if > they had gone through a full transfer instead? Correct. Why not? Just see how many transfers in other RIRs. This mechanism work not very good for now. Sub-allocations is very good alternative for transfers. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. 01.10.2012 18:58 - Tore Anderson ???????(?): * LeaderTelecom B.V. > Our case: we don't have PA-allocated space. but we have many clients who > need IPs. We found ISP who won't make transfer, while this is not very > simple procedure, but ready to make sub-allocation. >?? > Current policy allows to do suballocations, but maximum size is /20 > every twelve months for one ISP. This is too small count. >?? > I suggest: remove restrictions for size of network and period > (possibility to suballocate without any restractions instead of twelve > months ). >?? > Pros: > 1. No any work for RIPE (transfers requered additional work from RIPE side) > 2. Simple and fast. Just register sub-allocation in RIPE Database. > 3. Allow effective and fast use IPv4 space. >?? > I think in nearest time question of using IP-addresees from other ISP > will be very popular and the more simple to use IPv4 addresses from > other LIRs is better for community. So there will not be any requirement whatsoever on the receiving ISP to justify their need for the received block, in the way they would have if they had gone through a full transfer instead? Best regards, -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com/ [1] http://www.redpill-linpro.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Wed Oct 3 10:38:35 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Wed, 3 Oct 2012 12:38:35 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <506BD8FD.2040409@redpill-linpro.com> References: <506BD8FD.2040409@redpill-linpro.com><50644B56.8070805@redpill-linpro.com><1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349211282.729444.130178216.241366.2@otrs.hostingconsult.ru> Message-ID: <1349253515.662609.658785837.241366.2@otrs.hostingconsult.ru> Dear?Tore, > I question the wisdom of abolishing the need-based mechanism for > sub-allocations exclusively, when (to the best of my knowledge) all > other mechanisms to obtain number resources in all other regions are > need-based. Need-based princip make sense only until RIR has IPv4 for allocations. I understand that it was many years and it is as habit. > > Just see how many transfers in other RIRs. This mechanism work not very good > > for now. > How come? > In any case, if the transfer policy is broken somehow, why not fix it? Transfers good for permanent transfer. For temporary transfers better option sub-allocations while if you transfer IPs for some time than you get them back and see that they are in spamhouse and other black lists. In case of sub-allocation IPs in your control and you can regulate it.? -- Kind regards, Alexey Ivanov LeaderTelecom B.V.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at leon.pl Wed Oct 3 12:55:53 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 03 Oct 2012 12:55:53 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 Message-ID: <506C19B9.1010001@leon.pl> hello, I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? Regards, Marcin From nick at inex.ie Wed Oct 3 13:15:03 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 03 Oct 2012 12:15:03 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <506C19B9.1010001@leon.pl> References: <506C19B9.1010001@leon.pl> Message-ID: <506C1E37.8040209@inex.ie> On 03/10/2012 11:55, Marcin Kuczera wrote: > I'am lost a little bit, what is the current status of policy, that would Hi Marcin, There was extensive discussion about this at the RIPE66 meeting, where it was clear that there were both serious problems with the existing proposal (2012-04) and also a lack of consensus. As the proposal author, I'm currently thinking about what is the best way to deal with the problems. Input is welcome, either on this mailing list, or offline. Nick From richih.mailinglist at gmail.com Wed Oct 3 13:36:26 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 3 Oct 2012 13:36:26 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <506C1E37.8040209@inex.ie> References: <506C19B9.1010001@leon.pl> <506C1E37.8040209@inex.ie> Message-ID: Could you summarize the issues and challenges for the benefit of those not present at RIPE66? I consider this issue Rather Important and would love to give input if useful. Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Oct 3 13:41:50 2012 From: gert at space.net (Gert Doering) Date: Wed, 3 Oct 2012 13:41:50 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <506C19B9.1010001@leon.pl> References: <506C19B9.1010001@leon.pl> Message-ID: <20121003114150.GO13776@Space.Net> Hi, On Wed, Oct 03, 2012 at 12:55:53PM +0200, Marcin Kuczera wrote: > I'am lost a little bit, what is the current status of policy, that would > allow single /24 PI IPv4 assignment from the last /8 ??? "Too controversial to go forward". The proposer (Nick Hilliard) took in all the feedback and will come up with a new version of the proposal that might reach 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 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Wed Oct 3 13:44:30 2012 From: gert at space.net (Gert Doering) Date: Wed, 3 Oct 2012 13:44:30 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <506C19B9.1010001@leon.pl> <506C1E37.8040209@inex.ie> Message-ID: <20121003114430.GP13776@Space.Net> Hi, On Wed, Oct 03, 2012 at 01:36:26PM +0200, Richard Hartmann wrote: > Could you summarize the issues and challenges for the benefit of those not > present at RIPE66? We'll try to do that quickly after RIPE66 (which is going to take place in May 2013). Before that is going to be a bit of a challenge. In essence the questions raised at the RIPE*65* meeting last week are similar to what has been worded on the list before - fairness, distribution of the last remaining IPv4 address, money ("price per /24 or /22"). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From job at instituut.net Wed Oct 3 13:39:04 2012 From: job at instituut.net (Job Snijders) Date: Wed, 3 Oct 2012 14:39:04 +0300 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <506C19B9.1010001@leon.pl> <506C1E37.8040209@inex.ie> Message-ID: <24466E23-570D-45A1-96C9-7453B098CA3B@instituut.net> Hi, On Oct 3, 2012, at 2:36 PM, Richard Hartmann wrote: > Could you summarize the issues and challenges for the benefit of those not present at RIPE66? I plan on attending to RIPE66 on May 13th, 2013. After the conference I'd be happy to give you a executive summary. Must be some kind of time-zone thing that some of us already attended. ;-) - Job From nick at inex.ie Wed Oct 3 13:51:14 2012 From: nick at inex.ie (Nick Hilliard) Date: Wed, 03 Oct 2012 12:51:14 +0100 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <24466E23-570D-45A1-96C9-7453B098CA3B@instituut.net> References: <506C19B9.1010001@leon.pl> <506C1E37.8040209@inex.ie> <24466E23-570D-45A1-96C9-7453B098CA3B@instituut.net> Message-ID: <506C26B2.3060903@inex.ie> On 03/10/2012 12:39, Job Snijders wrote: > I plan on attending to RIPE66 on May 13th, 2013. After the conference > I'd be happy to give you a executive summary. Must be some kind of > time-zone thing that some of us already attended. ;-) Obviously, I view long term planning as very important. This is a Good thing. :-) Nick From jan at go6.si Wed Oct 3 14:20:58 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 03 Oct 2012 14:20:58 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <20121003114150.GO13776@Space.Net> References: <506C19B9.1010001@leon.pl> <20121003114150.GO13776@Space.Net> Message-ID: <506C2DAA.3040509@go6.si> On 10/3/12 1:41 PM, Gert Doering wrote: > Hi, > > On Wed, Oct 03, 2012 at 12:55:53PM +0200, Marcin Kuczera wrote: >> I'am lost a little bit, what is the current status of policy, that would >> allow single /24 PI IPv4 assignment from the last /8 ??? > > "Too controversial to go forward". It is a "yes" or "no" question, afaik :) Cheers, Jan From sander at steffann.nl Wed Oct 3 15:17:43 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 3 Oct 2012 15:17:43 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: <506C19B9.1010001@leon.pl> References: <506C19B9.1010001@leon.pl> Message-ID: Hello Marcin, > I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? You can find the status here: http://www.ripe.net/ripe/policies/proposals/2012-04 The policy proposal is in the review phase and under discussion until the 8th of October. Sander Steffann APWG co-chair From james.blessing at despres.co.uk Wed Oct 3 18:01:50 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 3 Oct 2012 17:01:50 +0100 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> Message-ID: On 3 October 2012 15:21, LeaderTelecom B.V. wrote: > You can sub-allocate up to a /20 every twelve months to a single downstream > Internet Service Provider (ISP). The minimum sub-allocation size is a /24. > This is the smallest prefix length that can be reverse delegated and that > allows for a reasonable number of small assignments to be made by a > downstream network operator. Okay So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations? J -- James Blessing 07989 039 476 From richih.mailinglist at gmail.com Wed Oct 3 23:15:35 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 3 Oct 2012 23:15:35 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <506C19B9.1010001@leon.pl> Message-ID: I can't inline my replies on Android, sorry. The official status page is of limited use in this context, but the official date/timeline _is_ good to be reminded of; thanks. PS: I didn't attend and simply stole the 66 from Nick ;) Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Thu Oct 4 11:24:42 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Thu, 04 Oct 2012 11:24:42 +0200 Subject: [address-policy-wg] 2012-06 Draft Document and Impact Analysis will be produced (Revert "Run Out Fairly" after IPv4 depletion) Message-ID: Dear Colleagues, The discussion period for the proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-06 Regards Emilio Madaio Policy Development Officer RIPE NCC From pooranm at in2cable.com Thu Oct 4 12:10:56 2012 From: pooranm at in2cable.com (pooranmittal) Date: Thu, 4 Oct 2012 15:40:56 +0530 Subject: [address-policy-wg] address-policy-wg Digest, Vol 14, Issue 4 References: Message-ID: <0920D1FC5CBA49779C3B752EA60A153D@imcl123> Hi, Myself Pooran Mittal, member of APNIC [IMCL-IN] with AS 17665. How RIPE can help me to get IPV4 addresses. Please help me. Regards Pooran Mittal ----- Original Message ----- From: To: Sent: Thursday, October 04, 2012 3:30 PM Subject: address-policy-wg Digest, Vol 14, Issue 4 > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Status of /24 PI IPv4 from last /8 (Jan Zorz @ go6.si) > 2. Re: Status of /24 PI IPv4 from last /8 (Sander Steffann) > 3. Re: [Ticket#2012092701011684] Sub-allocations - fast and > simple re-using IP-addresses (James Blessing) > 4. Re: Status of /24 PI IPv4 from last /8 (Richard Hartmann) > 5. 2012-06 Draft Document and Impact Analysis will be produced > (Revert "Run Out Fairly" after IPv4 depletion) (Emilio Madaio) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 03 Oct 2012 14:20:58 +0200 > From: "Jan Zorz @ go6.si" > Subject: Re: [address-policy-wg] Status of /24 PI IPv4 from last /8 > To: address-policy-wg at ripe.net > Message-ID: <506C2DAA.3040509 at go6.si> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/3/12 1:41 PM, Gert Doering wrote: >> Hi, >> >> On Wed, Oct 03, 2012 at 12:55:53PM +0200, Marcin Kuczera wrote: >>> I'am lost a little bit, what is the current status of policy, that would >>> allow single /24 PI IPv4 assignment from the last /8 ??? >> >> "Too controversial to go forward". > > It is a "yes" or "no" question, afaik :) > > Cheers, Jan > > > > > ------------------------------ > > Message: 2 > Date: Wed, 3 Oct 2012 15:17:43 +0200 > From: Sander Steffann > Subject: Re: [address-policy-wg] Status of /24 PI IPv4 from last /8 > To: Marcin Kuczera > Cc: "address-policy-wg at ripe.net" > Message-ID: > Content-Type: text/plain; charset=iso-8859-1 > > Hello Marcin, > >> I'am lost a little bit, what is the current status of policy, that would >> allow single /24 PI IPv4 assignment from the last /8 ??? > > You can find the status here: > http://www.ripe.net/ripe/policies/proposals/2012-04 > The policy proposal is in the review phase and under discussion until the > 8th of October. > > Sander Steffann > APWG co-chair > > > > > ------------------------------ > > Message: 3 > Date: Wed, 3 Oct 2012 17:01:50 +0100 > From: James Blessing > Subject: Re: [address-policy-wg] [Ticket#2012092701011684] > Sub-allocations - fast and simple re-using IP-addresses > To: Address Policy Working Group > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 3 October 2012 15:21, LeaderTelecom B.V. wrote: >> You can sub-allocate up to a /20 every twelve months to a single >> downstream >> Internet Service Provider (ISP). The minimum sub-allocation size is a >> /24. >> This is the smallest prefix length that can be reverse delegated and that >> allows for a reasonable number of small assignments to be made by a >> downstream network operator. > > Okay > > So wouldn't the best change be to allow up to allocation window per > annum plus an ability to go via the RIPE NCC for further > sub-allocations? > > J > -- > > James Blessing > 07989 039 476 > > > > ------------------------------ > > Message: 4 > Date: Wed, 3 Oct 2012 23:15:35 +0200 > From: Richard Hartmann > Subject: Re: [address-policy-wg] Status of /24 PI IPv4 from last /8 > To: Sander Steffann > Cc: Marcin Kuczera , address-policy-wg at ripe.net > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I can't inline my replies on Android, sorry. > > The official status page is of limited use in this context, but the > official date/timeline _is_ good to be reminded of; thanks. > > PS: I didn't attend and simply stole the 66 from Nick ;) > > Sent by mobile; excuse my brevity. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20121003/9263118a/attachment-0001.html > > ------------------------------ > > Message: 5 > Date: Thu, 04 Oct 2012 11:24:42 +0200 > From: Emilio Madaio > Subject: [address-policy-wg] 2012-06 Draft Document and Impact > Analysis will be produced (Revert "Run Out Fairly" after IPv4 > depletion) > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Message-ID: > > > Dear Colleagues, > > The discussion period for the proposed change to RIPE Document > ripe-553, "IPv4 Address Allocation and Assignment Policies for the > RIPE NCC Service Region", has ended. > > > A draft document and the RIPE NCC Impact Analysis will now be prepared > for review. We will publish the documents shortly and we will make an > announcement. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > > > End of address-policy-wg Digest, Vol 14, Issue 4 > ************************************************ From marcin at leon.pl Fri Oct 5 13:17:28 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Fri, 05 Oct 2012 13:17:28 +0200 Subject: [address-policy-wg] Status of /24 PI IPv4 from last /8 In-Reply-To: References: <506C19B9.1010001@leon.pl> Message-ID: <506EC1C8.6080506@leon.pl> On 2012-10-03 15:17, Sander Steffann wrote: > Hello Marcin, > >> I'am lost a little bit, what is the current status of policy, that would allow single /24 PI IPv4 assignment from the last /8 ??? > You can find the status here: http://www.ripe.net/ripe/policies/proposals/2012-04 > The policy proposal is in the review phase and under discussion until the 8th of October. > For me looks good, have my support. Marcin From richih.mailinglist at gmail.com Sat Oct 6 01:10:10 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 6 Oct 2012 01:10:10 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 14, Issue 4 In-Reply-To: <0920D1FC5CBA49779C3B752EA60A153D@imcl123> References: <0920D1FC5CBA49779C3B752EA60A153D@imcl123> Message-ID: If you operate in the RIPE region, you can register as LIR and you will get a /22. Not more, not less. This is not an APWG issue, though. Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Tue Oct 9 00:33:48 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Tue, 9 Oct 2012 02:33:48 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> Message-ID: <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> Dear?James, > So wouldn't the best change be to allow up to allocation window > per?annum plus an ability to go via the RIPE NCC for further >?sub-allocations? What you mean when tell about "allocation window"? Do you mean?assignment window?? -- Kind regards, Alexey Ivanov 03.10.2012 20:02 - James Blessing ???????(?): On 3 October 2012 15:21, LeaderTelecom B.V. wrote: > You can sub-allocate up to a /20 every twelve months to a single downstream > Internet Service Provider (ISP). The minimum sub-allocation size is a /24. > This is the smallest prefix length that can be reverse delegated and that > allows for a reasonable number of small assignments to be made by a > downstream network operator. Okay So wouldn't the best change be to allow up to allocation window per annum plus an ability to go via the RIPE NCC for further sub-allocations? J -- James Blessing 07989 039 476 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Oct 9 11:03:06 2012 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2012 11:03:06 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> Message-ID: <20121009090306.GM13776@Space.Net> Hi, On Tue, Oct 09, 2012 at 02:33:48AM +0400, LeaderTelecom B.V. wrote: > > So wouldn't the best change be to allow up to allocation window > > per?annum plus an ability to go via the RIPE NCC for further > >?sub-allocations? > > What you mean when tell about "allocation window"? Do you mean?assignment > window?? Sub-Allocations actually have their own "window" - one /20 per receipient per annum. Not coupled to the "assignment window". James' proposal has its merits, but OTOH, just loosening up sub-allocations might be the approach more appropriate for "the time we're living through". When this policy was initially written, there was a) no experience with sub-allocations, so I was careful, and b) worries that this might lead to LIRs sub-allocating all their space out the window, and then ending up in lengthy discussions with the NCC hostmasters - so a barrier was built in that was reasonable for the time and the envisioned usage ("customers that run ISP-ish businesses and need larger chunks of addresses to handle their customer allocations themselves"). While we still do not have much experience with sub-allocations, the warning "if you hand it all out, you might not get new space easily, so be wary" is moot - it's now "if you hand it out, there will not be any more space, period!", and LIRs should have noticed *that* by now... Gert Doering -- APWG chair and author of the IPv4 sub-allocation policy :-) -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tore.anderson at redpill-linpro.com Tue Oct 9 12:16:24 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 09 Oct 2012 12:16:24 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <20121009090306.GM13776@Space.Net> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> Message-ID: <5073F978.3030304@redpill-linpro.com> * Gert Doering > James' proposal has its merits, but OTOH, just loosening up sub-allocations > might be the approach more appropriate for "the time we're living through". > > [...] > > While we still do not have much experience with sub-allocations, the > warning "if you hand it all out, you might not get new space easily, > so be wary" is moot - it's now "if you hand it out, there will not be > any more space, period!", and LIRs should have noticed *that* by now... The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here. It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays? If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From sander at steffann.nl Tue Oct 9 12:39:42 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 9 Oct 2012 12:39:42 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073F978.3030304@redpill-linpro.com> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> Message-ID: <1C088D2A-2CE2-4E67-96A9-4950357D1726@steffann.nl> Hi Tore, > The way I see it, this argument applies equally well to LIR->EU > assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand > what makes sub-allocations special here. > > It would IMHO be much more interesting to see a proposal that would > retire the needs-based principle completely for all forms of IPv4 > delegations (that aren't taken from the NCC pool). Does it really serve > any useful purpose nowadays? > > If some LIR wants to give away (assign, transfer, sub-allocate - > whatever) all their remaining free space to someone who doesn't really > need it - why not let them? It won't impact me or anyone else since > their wasteful spending can no longer translate into an increased draw > from the shared pool. I, on the other hand, would certainly not miss the > assignment request documentation bureaucracy. Call for feedback: I am very interested in how the working group feels about such an idea these days now that the normal RIPE NCC IPv4 pool has run out. Thank you, Sander Steffann APWG co-chair From michiel at klaver.it Tue Oct 9 12:36:32 2012 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 09 Oct 2012 12:36:32 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073F978.3030304@redpill-linpro.com> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> Message-ID: <5073FE30.2040903@klaver.it> Removing the needs-based requirement would break open the entire IPv4 market, letting big corporations to buy everything available and then decide who they are willing to sell it for the highest price. IP addresses will become a tool to obstruct competitors, wipe-out all smaller players and locking the market for newcomers. An authority validating each request with the current policies could somewhat prevent that from happening. At 09-10-2012 12:16, Tore Anderson wrote: > * Gert Doering > >> James' proposal has its merits, but OTOH, just loosening up sub-allocations >> might be the approach more appropriate for "the time we're living through". >> >> [...] >> >> While we still do not have much experience with sub-allocations, the >> warning "if you hand it all out, you might not get new space easily, >> so be wary" is moot - it's now "if you hand it out, there will not be >> any more space, period!", and LIRs should have noticed *that* by now... > > The way I see it, this argument applies equally well to LIR->EU > assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand > what makes sub-allocations special here. > > It would IMHO be much more interesting to see a proposal that would > retire the needs-based principle completely for all forms of IPv4 > delegations (that aren't taken from the NCC pool). Does it really serve > any useful purpose nowadays? > > If some LIR wants to give away (assign, transfer, sub-allocate - > whatever) all their remaining free space to someone who doesn't really > need it - why not let them? It won't impact me or anyone else since > their wasteful spending can no longer translate into an increased draw > from the shared pool. I, on the other hand, would certainly not miss the > assignment request documentation bureaucracy. > From tore.anderson at redpill-linpro.com Tue Oct 9 12:58:25 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 09 Oct 2012 12:58:25 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073FE30.2040903@klaver.it> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <5073FE30.2040903@klaver.it> Message-ID: <50740351.7000707@redpill-linpro.com> * Michiel Klaver > Removing the needs-based requirement would break open the entire IPv4 > market, letting big corporations to buy everything available and then decide > who they are willing to sell it for the highest price. > > IP addresses will become a tool to obstruct competitors, wipe-out all > smaller players and locking the market for newcomers. An authority > validating each request with the current policies could somewhat prevent > that from happening. You could say the same thing about real estate or pretty much any other freely traded resource in the world, and yet the sky isn't falling. In a competitive market, supply and demand will regulate the prices. Otherwise, there's plenty of laws governing cartels, monopolies, price fixing, anti-competitive practises, and so forth. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From oalfageme at euskaltel.com Tue Oct 9 13:00:37 2012 From: oalfageme at euskaltel.com (Octavio Alfageme) Date: Tue, 9 Oct 2012 13:00:37 +0200 Subject: [address-policy-wg] RIPE-552 Impact of extending initial allocation from /32 to /29 In-Reply-To: References: Message-ID: <926B3F6738AA624F93C55B77DBE2ED6002D0E392@CORREO.corporativo.euskaltel.es> Dear all, According to RIPE552 LIRs may easily request the extension of its IPv6 /32 initial allocation up to a /29. However, if we take a look at the reservation made for some initial /32 allocations, we find that it is /30. For instance (ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest): ripencc|FR|ipv6|2a00:7900::|32|20110214|allocated ripencc|NL|ipv6|2a00:7940::|32|20120118|allocated ripencc|RU|ipv6|2a00:7980::|32|20110509|allocated ripencc|DE|ipv6|2a00:79c0::|32|20120119|allocated ripencc|NO|ipv6|2a00:7a00::|32|20110120|allocated ripencc|GB|ipv6|2a00:7a40::|32|20120119|allocated ripencc|AT|ipv6|2a00:7a80::|32|20110509|allocated ripencc|RU|ipv6|2a00:7ac0::|32|20120119|allocated ripencc|ES|ipv6|2a00:7b00::|32|20110214|allocated In case any of this LIRs wants to request the extension to /29, would he receive a 'brand new' /29 and will have to give its original /32 back? I would be grateful if you could clarify me the process. No need to say that my company is one of the LIRs affected by this situation. Kind regards Octavio Alfageme From sander at steffann.nl Tue Oct 9 13:08:27 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 9 Oct 2012 13:08:27 +0200 Subject: [address-policy-wg] RIPE-552 Impact of extending initial allocation from /32 to /29 In-Reply-To: <926B3F6738AA624F93C55B77DBE2ED6002D0E392@CORREO.corporativo.euskaltel.es> References: <926B3F6738AA624F93C55B77DBE2ED6002D0E392@CORREO.corporativo.euskaltel.es> Message-ID: Hi, > According to RIPE552 LIRs may easily request the extension of its IPv6 > /32 initial allocation up to a /29. However, if we take a look at the > reservation made for some initial /32 allocations, we find that it is > /30. For instance > (ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest): > > ripencc|FR|ipv6|2a00:7900::|32|20110214|allocated > ripencc|NL|ipv6|2a00:7940::|32|20120118|allocated > ripencc|RU|ipv6|2a00:7980::|32|20110509|allocated > ripencc|DE|ipv6|2a00:79c0::|32|20120119|allocated > ripencc|NO|ipv6|2a00:7a00::|32|20110120|allocated > ripencc|GB|ipv6|2a00:7a40::|32|20120119|allocated > ripencc|AT|ipv6|2a00:7a80::|32|20110509|allocated > ripencc|RU|ipv6|2a00:7ac0::|32|20120119|allocated > ripencc|ES|ipv6|2a00:7b00::|32|20110214|allocated > > In case any of this LIRs wants to request the extension to /29, would he > receive a 'brand new' /29 and will have to give its original /32 back? I > would be grateful if you could clarify me the process. No need to say > that my company is one of the LIRs affected by this situation. You're one nibble off :-) Those /32s can all be expanded to /26s even. For example 2a00:7900::/26 is 2a00:7900:: to 2a00:793f:ffff:ffff:ffff:ffff:ffff:ffff. So expanding such a /32 to a /29 is no problem at all. - Sander From oalfageme at euskaltel.com Tue Oct 9 13:09:53 2012 From: oalfageme at euskaltel.com (Octavio Alfageme) Date: Tue, 9 Oct 2012 13:09:53 +0200 Subject: [address-policy-wg] RIPE-552 Impact of extending initial allocation from /32 to /29 In-Reply-To: References: <926B3F6738AA624F93C55B77DBE2ED6002D0E392@CORREO.corporativo.euskaltel.es> Message-ID: <926B3F6738AA624F93C55B77DBE2ED6002D0E394@CORREO.corporativo.euskaltel.es> Ouchhh!!! I'm terribly sorry. ;-) Thank you, Sander. Octavio -----Mensaje original----- De: Sander Steffann [mailto:sander at steffann.nl] Enviado el: martes, 09 de octubre de 2012 13:08 Para: Octavio Alfageme CC: address-policy-wg at ripe.net Asunto: Re: [address-policy-wg] RIPE-552 Impact of extending initial allocation from /32 to /29 Hi, > According to RIPE552 LIRs may easily request the extension of its IPv6 > /32 initial allocation up to a /29. However, if we take a look at the > reservation made for some initial /32 allocations, we find that it is > /30. For instance > (ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest): > > ripencc|FR|ipv6|2a00:7900::|32|20110214|allocated > ripencc|NL|ipv6|2a00:7940::|32|20120118|allocated > ripencc|RU|ipv6|2a00:7980::|32|20110509|allocated > ripencc|DE|ipv6|2a00:79c0::|32|20120119|allocated > ripencc|NO|ipv6|2a00:7a00::|32|20110120|allocated > ripencc|GB|ipv6|2a00:7a40::|32|20120119|allocated > ripencc|AT|ipv6|2a00:7a80::|32|20110509|allocated > ripencc|RU|ipv6|2a00:7ac0::|32|20120119|allocated > ripencc|ES|ipv6|2a00:7b00::|32|20110214|allocated > > In case any of this LIRs wants to request the extension to /29, would he > receive a 'brand new' /29 and will have to give its original /32 back? I > would be grateful if you could clarify me the process. No need to say > that my company is one of the LIRs affected by this situation. You're one nibble off :-) Those /32s can all be expanded to /26s even. For example 2a00:7900::/26 is 2a00:7900:: to 2a00:793f:ffff:ffff:ffff:ffff:ffff:ffff. So expanding such a /32 to a /29 is no problem at all. - Sander From gert at space.net Tue Oct 9 14:11:51 2012 From: gert at space.net (Gert Doering) Date: Tue, 9 Oct 2012 14:11:51 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073F978.3030304@redpill-linpro.com> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> Message-ID: <20121009121151.GO13776@Space.Net> Hi, On Tue, Oct 09, 2012 at 12:16:24PM +0200, Tore Anderson wrote: > > While we still do not have much experience with sub-allocations, the > > warning "if you hand it all out, you might not get new space easily, > > so be wary" is moot - it's now "if you hand it out, there will not be > > any more space, period!", and LIRs should have noticed *that* by now... > > The way I see it, this argument applies equally well to LIR->EU > assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand > what makes sub-allocations special here. Well, sub-allocation used to be special in the same way allocations are different than PI assignments - "the receipient is assumed to be an ISP-ish operation that provides (needs-based) assignment to lots of end-users". > It would IMHO be much more interesting to see a proposal that would > retire the needs-based principle completely for all forms of IPv4 > delegations (that aren't taken from the NCC pool). Does it really serve > any useful purpose nowadays? There are traces of needs-based still present in the system - like the transfer policy requiring the receipient to "document need" to the NCC to get the transfer approved (... and the ARIN folks flatly refusing cross-RIR transfers if the receipient RIR has no needs-based component). So if you permit LIRs to "just give away their stuff" and then go back to the NCC and claim "need!" (to get an incoming transfer approved), this is not without its own risks. (Not that we couldn't change the transfer policy towards "both parties tell the NCC, the NCC registers the transfer, done"... someone would have to propose that, though, and fight for 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 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From info at leadertelecom.nl Thu Oct 11 10:19:55 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 11 Oct 2012 12:19:55 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <20121009090306.GM13776@Space.Net> References: <20121009090306.GM13776@Space.Net> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> Message-ID: <1349943595.763839.613851546.241366.2@otrs.hostingconsult.ru> Dear?Gert, > When this policy was initially written, there was a) no experience with > sub-allocations, so I was careful, and b) worries that this might lead > to LIRs sub-allocating all their space out the window, and then ending > up in lengthy discussions with the NCC hostmasters - so a barrier was > built in that was reasonable for the time and the envisioned usage > ("customers that run ISP-ish businesses and need larger chunks of > addresses to handle their customer allocations themselves"). > While we still do not have much experience with sub-allocations, the > warning "if you hand it all out, you might not get new space easily, > so be wary" is moot - it's now "if you hand it out, there will not be > any more space, period!", and LIRs should have noticed *that* by now... I think for now all LIRs know that IPs in RIPE finished and they understand what they do if they will sub-allocate all IPs. And may be it make sense. For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. -- Kind regards, Alexey Ivanov -------------- next part -------------- An HTML attachment was scrubbed... URL: From poty at iiat.ru Thu Oct 11 10:25:48 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Thu, 11 Oct 2012 12:25:48 +0400 Subject: [address-policy-wg] FW: [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses Message-ID: >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Thu Oct 11 10:36:51 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 11 Oct 2012 12:36:51 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073F978.3030304@redpill-linpro.com> References: <5073F978.3030304@redpill-linpro.com> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> Message-ID: <1349944611.473339.652871289.241366.2@otrs.hostingconsult.ru> Dear?Tore, > The way I see it, this argument applies equally well to LIR->EU > assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand > what makes sub-allocations special here. Transfers are very useful for permanent transfer. ? Sub-allocations - for temporary use. This allows to control what happend's with IP-addresses while if they will be in black list (SpamHouse, etc..) - then impossible to use them in future. -- Kind regards, Alexey Ivanov 09.10.2012 14:16 - Tore Anderson ???????(?): * Gert Doering > James' proposal has its merits, but OTOH, just loosening up sub-allocations > might be the approach more appropriate for "the time we're living through". > > [...] > > While we still do not have much experience with sub-allocations, the > warning "if you hand it all out, you might not get new space easily, > so be wary" is moot - it's now "if you hand it out, there will not be > any more space, period!", and LIRs should have noticed *that* by now... The way I see it, this argument applies equally well to LIR->EU assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand what makes sub-allocations special here. It would IMHO be much more interesting to see a proposal that would retire the needs-based principle completely for all forms of IPv4 delegations (that aren't taken from the NCC pool). Does it really serve any useful purpose nowadays? If some LIR wants to give away (assign, transfer, sub-allocate - whatever) all their remaining free space to someone who doesn't really need it - why not let them? It won't impact me or anyone else since their wasteful spending can no longer translate into an increased draw from the shared pool. I, on the other hand, would certainly not miss the assignment request documentation bureaucracy. -- Tore Anderson Redpill Linpro AS - [1]http://www.redpill-linpro.com/ [1] http://www.redpill-linpro.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Thu Oct 11 12:34:42 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 11 Oct 2012 14:34:42 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: Message-ID: <1349951682.454943.918745268.241366.2@otrs.hostingconsult.ru> Dear?Vladislav, It is just one case. Anyway may be some company started big telecom project which was paused and they have IPs which they can't use in this moment.? -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 12:37 - ???????(?): >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov ? I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. ? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat -------------- next part -------------- An HTML attachment was scrubbed... URL: From poty at iiat.ru Thu Oct 11 12:44:16 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Thu, 11 Oct 2012 14:44:16 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses Message-ID: And for this very special ?may? we should treat the whole existing idea as obsolete? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat From: LeaderTelecom B.V. [mailto:info at leadertelecom.nl] Sent: Thursday, October 11, 2012 2:35 PM To: Potapov Vladislav Cc: address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear Vladislav, It is just one case. Anyway may be some company started big telecom project which was paused and they have IPs which they can't use in this moment. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 12:37 - ???????(?): >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Thu Oct 11 13:20:52 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 11 Oct 2012 15:20:52 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5073FE30.2040903@klaver.it> References: <5073FE30.2040903@klaver.it> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> Message-ID: <1349954452.607057.0375212.241366.2@otrs.hostingconsult.ru> Dear?Michiel, > Removing the needs-based requirement would break open the entire IPv4 > market, letting big corporations to buy everything available and then decide > who they are willing to sell it for the highest price. ? I think big companies can approve via RIPE any transfers while they have? thousands work places, servers, and etc. If we discuss sub-allocations - then? allocated PA block won't changed. And they can't sell too high. ? > IP addresses will become a tool to obstruct competitors, wipe-out all > smaller players and locking the market for newcomers.? ? Newcomers can get 1024 IPv4 as new LIR. I think any restrictions only increase? prices. All people usually busy (who not busy here?). If someone has IP and can? very simple give it to someone - then more IPs will be available and prices for? IP will be lower. ? I had this situation - in one company told me that they can sub-allocate IP, but don't have any time for bureaucracy. ? > An authority > validating each request with the current policies could somewhat prevent > that from happening. ? Aha.. Just check big blocks (100k IPs and more) which were allocated before? IPv4 were finished in RIPE. Of course I think all was made as it was written in? policy. It is just a black hole in policy.? ? Conclusion: let?s make simple regulation. Less paperwork, more freedom. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamed at skydsl.ir Thu Oct 11 13:39:53 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Thu, 11 Oct 2012 15:09:53 +0330 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1349954452.607057.0375212.241366.2@otrs.hostingconsult.ru> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <5073FE30.2040903@klaver.it> <1349954452.607057.0375212.241366.2@otrs.hostingconsult.ru> Message-ID: I agree with Alexey about any restrictions only increase prices. Hamed -- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Thu Oct 11 13:55:43 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 11 Oct 2012 15:55:43 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: Message-ID: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> Dear?Vladislav, It is not just "may". It is real case.? Permanenent transfer cost 10USD per 1 IP. It is too high. We won't pay this money. We ready pay monthly. It this case the best way to give legal IPs for us - make "sub allocation". But we have restricion in policy - another LIR can sub-allocate only /20?every twelve months. This is too small size. While we need assign now in several times more. And as soon as we will assign this space - we will receive additional requests, but the same supplier by current policy can't give us additional networks while he can do it only one time in twelve months.? About "may" - it was an example when can be sub-allocated all space. While Gert Doering wrote about this case. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 14:51 - ???????(?): And for this very special ?may? we should treat the whole existing idea as obsolete? ? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat ? From: LeaderTelecom B.V. [mailto:info at leadertelecom.nl] Sent: Thursday, October 11, 2012 2:35 PM To: Potapov Vladislav Cc: address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear?Vladislav, It is just one case. Anyway may be some company started big telecom project which was paused and they have IPs which they can't use in this moment.? -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 12:37 - ???????(?): >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov ? I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. ? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Thu Oct 11 15:27:48 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 11 Oct 2012 15:27:48 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <20121009121151.GO13776@Space.Net> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> Message-ID: <5076C954.70701@CC.UniVie.ac.at> Gert Doering wrote: [...] > There are traces of needs-based still present in the system AFAIK RFC2050 still is in effect. All more recent suggestions to get it modified or retired were not successful. I got to understand that messing around with it [c|w]ould have far-reaching unwanted consequences for the whole IP Address Distribution System. FWIW, Wilfried. From gert at space.net Thu Oct 11 15:45:51 2012 From: gert at space.net (Gert Doering) Date: Thu, 11 Oct 2012 15:45:51 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <5076C954.70701@CC.UniVie.ac.at> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> <5076C954.70701@CC.UniVie.ac.at> Message-ID: <20121011134551.GD13776@Space.Net> Hi, On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote: > Gert Doering wrote: > > [...] > > There are traces of needs-based still present in the system > > AFAIK RFC2050 still is in effect. > > All more recent suggestions to get it modified or retired were not successful. > > I got to understand that messing around with it [c|w]ould have far-reaching > unwanted consequences for the whole IP Address Distribution System. Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly fundamental consequences for the environment in which we operate, and at least one of the pillars of RFC2050 ("conservation") is not exactly relevant anymore. I consider RFC2050 a very useful document to establish principles, but it can not be binding - and in doubt, the bottom-up community based process will win. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From jan at go6.si Fri Oct 12 12:04:33 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 12 Oct 2012 12:04:33 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <5073FE30.2040903@klaver.it> <1349954452.607057.0375212.241366.2@otrs.hostingconsult.ru> Message-ID: <5077EB31.6050601@go6.si> On 10/11/12 1:39 PM, Hamed Shafaghi wrote: > > I agree with Alexey about any restrictions only increase prices. I'm not sure we are still inside the scope limits of Address Policy WG here :) Chairs will correct me if I'm wrong. Cheers, Jan From sander at steffann.nl Fri Oct 12 13:28:50 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 12 Oct 2012 13:28:50 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> Message-ID: Hi Alexey, > Permanenent transfer cost [...] Please remember that the current transfer policy explicitly states "This re-allocation may be on either a permanent or non-permanent basis." so you can already use the current transfer policy for temporary transfers. - Sander From stolpe at resilans.se Fri Oct 12 13:48:37 2012 From: stolpe at resilans.se (Daniel Stolpe) Date: Fri, 12 Oct 2012 13:48:37 +0200 (CEST) Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1C088D2A-2CE2-4E67-96A9-4950357D1726@steffann.nl> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <1C088D2A-2CE2-4E67-96A9-4950357D1726@steffann.nl> Message-ID: On Tue, 9 Oct 2012, Sander Steffann wrote: > Hi Tore, > >> The way I see it, this argument applies equally well to LIR->EU >> assignments, and to {LIR,EU}->{LIR,EU} transfers. I don't understand >> what makes sub-allocations special here. >> >> It would IMHO be much more interesting to see a proposal that would >> retire the needs-based principle completely for all forms of IPv4 >> delegations (that aren't taken from the NCC pool). Does it really serve >> any useful purpose nowadays? >> >> If some LIR wants to give away (assign, transfer, sub-allocate - >> whatever) all their remaining free space to someone who doesn't really >> need it - why not let them? It won't impact me or anyone else since >> their wasteful spending can no longer translate into an increased draw >> from the shared pool. I, on the other hand, would certainly not miss the >> assignment request documentation bureaucracy. > > Call for feedback: I am very interested in how the working group feels about such an idea these days now that the normal RIPE NCC IPv4 pool has run out. I think Tore has a point. The rules for IPv4 were useful as long as there were IPv4 addresses to hand out but now they just makes life harder for those who need addresses and if we have a lot of regulations to stop an open market we will just have higher prices on a black market. I would also like to see IPv6 policies much more simple. The situation today is that customers applying for IPv6 space are rejected completely or if they a number of prefixes (i.e. an international clouds based company wants one per site) they get some, but not fewer than they wanted. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From emadaio at ripe.net Fri Oct 12 14:21:45 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 12 Oct 2012 14:21:45 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Last Call for Comments on Draft Document for Reverse Delegation Policy ripe-302 Message-ID: <50780B59.6040404@ripe.net> Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC published for community review the draft policy document ripe-302, "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region". Information on the Cosmetic Surgery Project and the draft policy document are available at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents The Review Phase for this document has ended. After the feedback received, the Address Policy Working Group co-chairs decided to move into the Last Call period for comments. This period will last until 26 October 2012. We encourage you to read this merged version. Please send any comments to address-policy-wg at ripe.net by 26 October 2012. Best Regards Emilio Madaio RIPE NCC Policy Development Officer From gert at space.net Fri Oct 12 14:26:19 2012 From: gert at space.net (Gert Doering) Date: Fri, 12 Oct 2012 14:26:19 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <1C088D2A-2CE2-4E67-96A9-4950357D1726@steffann.nl> Message-ID: <20121012122619.GI13776@Space.Net> Hi, On Fri, Oct 12, 2012 at 01:48:37PM +0200, Daniel Stolpe wrote: > I would also like to see IPv6 policies much more simple. So do I, and I *am* working on that. But let's not intermix this into IPv4 discussions (otherwise we loose focus). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Niall.oReilly at ucd.ie Fri Oct 12 17:25:43 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 12 Oct 2012 16:25:43 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Last Call for Comments on Draft Document for Reverse Delegation Policy ripe-302 In-Reply-To: <50780B59.6040404@ripe.net> References: <50780B59.6040404@ripe.net> Message-ID: <77DA347D-40C4-4296-B13F-EDD6ABCDF254@ucd.ie> On 12 Oct 2012, at 13:21, Emilio Madaio wrote: > We encourage you to read this merged version. Please send any comments > to address-policy-wg at ripe.net by 26 October 2012. I have an objection on grammatical and aesthetic grounds. This seems particularly appropriate in the context of a "Cosmetic Surgery" review. > 2.0 Introduction > > The RIPE NCC provides the necessary support to enable resolution of IPv4 and IPv6 address space into domain names. This service is implemented under the in-addr.arpa and ip6.arpa sub domains described in [1] and [2]. "Sub" is a prefix, not an adjective. Please substitute for "sub domains" any of the following: "sub-domains" -- a hyphen is usually appropriate after a prefix; "subdomains" -- a well-established derived word needs no hyphen; "domains" -- no qualifying prefix is actually necessary, as both "in-addr.arpa" and "ip6.arpa" are domains, and the value of emphasizing their subsidiarity in this context is doubtful. Have a good weekend, everyone! /Niall From info at leadertelecom.nl Sun Oct 14 14:06:04 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Sun, 14 Oct 2012 16:06:04 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> Message-ID: <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Dear?Sander, > > Permanenent transfer cost [...] > Please remember that the current transfer policy explicitly states "This > re-allocation may be on either a permanent or non-permanent basis." so you can > already use the current transfer policy for temporary transfers. ?After temporary transfer you can receive back IPs which listed in Spamhouse. I don't know any company which will?temporary transfers IPs. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. 12.10.2012 15:29 - Sander Steffann ???????(?): Hi Alexey, > Permanenent transfer cost [...] Please remember that the current transfer policy explicitly states "This re-allocation may be on either a permanent or non-permanent basis." so you can already use the current transfer policy for temporary transfers. - Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sun Oct 14 14:10:26 2012 From: gert at space.net (Gert Doering) Date: Sun, 14 Oct 2012 14:10:26 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Message-ID: <20121014121026.GS13776@Space.Net> Hi, On Sun, Oct 14, 2012 at 04:06:04PM +0400, LeaderTelecom B.V. wrote: > > > Permanenent transfer cost [...] > > > Please remember that the current transfer policy explicitly states "This > > re-allocation may be on either a permanent or non-permanent basis." so you > can > > already use the current transfer policy for temporary transfers. > > ?After temporary transfer you can receive back IPs which listed in Spamhouse. > I don't know any company which will?temporary transfers IPs. So how is this different from a sub-allocation which is then listed in Spamhouse? I'm finding this argument difficult to understand. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sander at steffann.nl Sun Oct 14 14:23:24 2012 From: sander at steffann.nl (Sander Steffann) Date: Sun, 14 Oct 2012 14:23:24 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Message-ID: Hi, > > > Permanenent transfer cost [...] > > > Please remember that the current transfer policy explicitly states "This > > re-allocation may be on either a permanent or non-permanent basis." so you can > > already use the current transfer policy for temporary transfers. > > After temporary transfer you can receive back IPs which listed in Spamhouse. I don't know any company which will temporary transfers IPs. But exactly the same can happen with sub-allocated address space. Why would transfers be any different? At least with a transfer you can show that the responsibility for those addresses was (temporarily) transferred to another organisation. With sub-allocated addresses the responsibility remains with the original holder, who would then probably even have a bigger problem explaining everything and getting off the spam lists. This seems to be an argument *in favour* of using temporary transfers... Sander From info at leadertelecom.nl Sun Oct 14 14:34:44 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Sun, 14 Oct 2012 16:34:44 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <20121014121026.GS13776@Space.Net> References: <20121014121026.GS13776@Space.Net> <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Message-ID: <1350218084.439151.606113854.241366.2@otrs.hostingconsult.ru> Dear?Gert, > So how is this different from a sub-allocation which is then listed > in?Spamhouse??? > I'm finding this argument difficult to understand. When you make sub-allocation - you will receive abuses and discuss these issues with client and cancel agreement if it was broken by client. After temporary?transfer you can't receive abuses. You don't know anything about IPs until they will be returned back.?They are not under your control.? -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 14.10.2012 16:10 - Gert Doering ???????(?): Hi, On Sun, Oct 14, 2012 at 04:06:04PM +0400, LeaderTelecom B.V. wrote: > > > Permanenent transfer cost [...] > > > Please remember that the current transfer policy explicitly states "This > > re-allocation may be on either a permanent or non-permanent basis." so you > can > > already use the current transfer policy for temporary transfers. > > ?After temporary transfer you can receive back IPs which listed in Spamhouse. > I don't know any company which will?temporary transfers IPs. So how is this different from a sub-allocation which is then listed in Spamhouse??? I'm finding this argument difficult to understand. Gert Doering ????????-- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG????????????????????????Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14??????????Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen?????????????????? HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444????????????USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Sun Oct 14 14:44:52 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Sun, 14 Oct 2012 16:44:52 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Message-ID: <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> Dear?Sander, > But exactly the same can happen with sub-allocated address space. Why would > transfers be any different? At least with a transfer you can show that the > responsibility for those addresses was (temporarily) transferred to another > organisation. With sub-allocated addresses the responsibility remains with the > original holder, who would then probably even have a bigger problem explaining > everything and getting off the spam lists. > This seems to be an argument *in favour* of using temporary transfers... It is very difficult discuss with black lists delisting. Some of black lists can ignore requests.? It is better prevent blacklisting. If I understund well policy of transfers - minimal term of transfer - 2 years. It is too long too. I understund that it is normail for EU, but for Russia most of agreement usualy for 1 year. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team URL: [1]http://www.LeaderTelecom.nl/?-?IP- addresses URL: [2]http://www.GetWildcard.com/nl?- WildCard SSL certificates 14.10.2012 16:23 - Sander Steffann ???????(?): Hi, > > > Permanenent transfer cost [...] > > > Please remember that the current transfer policy explicitly states "This > > re-allocation may be on either a permanent or non-permanent basis." so you can > > already use the current transfer policy for temporary transfers. > >??After temporary transfer you can receive back IPs which listed in Spamhouse. I don't know any company which will temporary transfers IPs. But exactly the same can happen with sub-allocated address space. Why would transfers be any different? At least with a transfer you can show that the responsibility for those addresses was (temporarily) transferred to another organisation. With sub-allocated addresses the responsibility remains with the original holder, who would then probably even have a bigger problem explaining everything and getting off the spam lists. This seems to be an argument *in favour* of using temporary transfers... Sander ? [1] http://www.leadertelecom.nl/ [2] http://www.GetWildcard.com/nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sun Oct 14 14:53:03 2012 From: sander at steffann.nl (Sander Steffann) Date: Sun, 14 Oct 2012 14:53:03 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> Message-ID: <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> Hi, > It is very difficult discuss with black lists delisting. Some of black lists can ignore requests. IMHO blacklist operators should keep an eye on address transfers and adjust their lists accordingly. But what makes you think that abuse complaints will always reach the original holder of the address space and not only the holder of the sub-allocated space? > It is better prevent blacklisting. That is always true :-) > If I understund well policy of transfers - minimal term of transfer - 2 years. No it doesn't. It says that the organisation *receiving* the address space may not transfer it on within 24 months. There are no constraints in the policy about the term for temporary transfers. - Sander From garry at nethinks.com Sun Oct 14 16:54:07 2012 From: garry at nethinks.com (Garry Glendown) Date: Sun, 14 Oct 2012 16:54:07 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> Message-ID: <507AD20F.30800@nethinks.com> On 14.10.2012 14:53, Sander Steffann wrote: > Hi, > >> It is very difficult discuss with black lists delisting. Some of black lists can ignore requests. > IMHO blacklist operators should keep an eye on address transfers and adjust their lists accordingly. Seeing that some RBL providers seem to be more of an extortion business than spam prevention, I doubt you will have a hard time getting out of the lists quickly if required ... though, I don't see why this should be a problem preventing sub-allocations, as long as the original holder of the address space is aware of the risks, and is not so short in addresses that they need to be re-used right away once they are returned ... -garry From garry at nethinks.com Sun Oct 14 16:58:10 2012 From: garry at nethinks.com (Garry Glendown) Date: Sun, 14 Oct 2012 16:58:10 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <507AD20F.30800@nethinks.com> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> <507AD20F.30800@nethinks.com> Message-ID: <507AD302.9040904@nethinks.com> On 14.10.2012 16:54, Garry Glendown wrote: > I doubt you will have a hard time getting out of the lists quickly if > required ... This of course was supposed to read "I doubt you will get out of the list quickly" ... at least without paying for it ... -garry From randy at psg.com Sun Oct 14 19:41:26 2012 From: randy at psg.com (Randy Bush) Date: Sun, 14 Oct 2012 07:41:26 -1000 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> Message-ID: > I don't know any company which will?temporary transfers IPs. i have given multi-year loans, admittedly not transfers as they did not exist at the time, a number of times. i have space out on loan now. randy From sander at steffann.nl Mon Oct 15 10:21:45 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 15 Oct 2012 10:21:45 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350287051.659266.435403104.241366.2@otrs.hostingconsult.ru> References: <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> <1350287051.659266.435403104.241366.2@otrs.hostingconsult.ru> Message-ID: Hi, > Lets check RIPE-530: > > > Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a > > permanent or non-permanent basis. > > LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of > > the same address space to another LIR within 24 months of receiving the re-allocation. > > For temporary transfer we make 2 transfers: 1. from LIR A to LIR B. .... 2. Form LIR B to LIR A (back). While address space may not transfer it on within 24 months, so we can't transfer back earlier than in 2 years. Ah, there is the misunderstanding. Giving back the address space is not a separate transfer. It's part of the original (temporary) transfer. This rule is only to prevent people from selling addresses on. - Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Mon Oct 15 11:40:04 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Mon, 15 Oct 2012 13:40:04 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> <1350287051.659266.435403104.241366.2@otrs.hostingconsult.ru> Message-ID: <1350294004.293291.235973831.241366.2@otrs.hostingconsult.ru> Dear?Sander, > Ah, there is the misunderstanding. Giving back the address space is not a separate > transfer. It's part of the original (temporary) transfer. This rule is only to prevent people > from selling addresses on.? I understund this idea. I think it will be great to write that rule ( ...?24 months of receiving...?) work only for permanent transfers. Whyle formaly for now it is for any transfers. -- Kind regards, Alexey Ivanov LeaderTelecom B.V.? 15.10.2012 12:22 - Sander Steffann ???????(?): Hi, ? Lets check RIPE-530: > Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a > permanent or non-permanent basis. > LIRs that receive a re-allocation from another LIR cannot re-allocate complete or partial blocks of > the same address space to another LIR within 24 months of receiving the re-allocation. For temporary transfer we make 2 transfers: 1. from LIR A to LIR B. .... 2. Form LIR B to LIR A (back). While?address space may not?transfer it on within 24 months, so we can't transfer back earlier than in 2 years.? Ah, there is the misunderstanding. Giving back the address space is not a separate transfer. It's part of the original (temporary) transfer. This rule is only to prevent people from selling addresses on.? ? - Sander -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Oct 15 11:43:30 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 15 Oct 2012 11:43:30 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350294004.293291.235973831.241366.2@otrs.hostingconsult.ru> References: <8B32E70F-042C-4761-88F1-66A58B003B25@steffann.nl> <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350218692.775386.481522975.241366.2@otrs.hostingconsult.ru> <1350287051.659266.435403104.241366.2@otrs.hostingconsult.ru> <1350294004.293291.235973831.241366.2@otrs.hostingconsult.ru> Message-ID: > > Ah, there is the misunderstanding. Giving back the address space is not a separate > > transfer. It's part of the original (temporary) transfer. This rule is only to prevent people > > from selling addresses on. > > I understund this idea. I think it will be great to write that rule ( ... 24 months of receiving... ) work only for permanent transfers. Whyle formaly for now it is for any transfers. Yes, if you receive address space through a transfer the RIPE policy will not let you re-sell it within 24 months. When you have a temporary transfer the contract you have with the original holder will probably prohibit any re-selling at all. But again: giving back the addresses to the original holder is not a separate transfer, it's part of the original transfer, so the 24 month restriction doesn't even apply to giving back the address space. It's only about a potential *new* transfer. - Sander From info at leadertelecom.nl Mon Oct 15 11:59:26 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Mon, 15 Oct 2012 13:59:26 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <20121011134551.GD13776@Space.Net> References: <20121011134551.GD13776@Space.Net> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> <5076C954.70701@CC.UniVie.ac.at> Message-ID: <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> Dear?Gert, Agree with your opinion regards RFC 2050. Main idea this RFC:?This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Goals: > 1. Conservation: Fair distribution of globally unique Internet address space according to the > operational needs of the end-users and Internet Service Providers operating networks using this > address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address > space. This doesn't required anymore. While RIPE doesn't have free space for distributing. It was very useful before and respect for people who wrote it while principes in this RFC were very useful long time. But for now it?looks as deprecated and not updated. Some words from RFC which looks like depriceated: ...Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and AP- NIC serving the Asian Pacific region... ...3.2 Network Engineering Plans.. 2. a description of the network topology 3. a description of the network routing plans, including the routing protocols to be used as well as any limitations.. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team URL: [1]http://www.LeaderTelecom.nl/?-?IP- addresses URL: [2]http://www.GetWildcard.com/nl?- WildCard SSL certificates 11.10.2012 17:46 - Gert Doering ???????(?): Hi, On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote: > Gert Doering wrote: > > [...] > > There are traces of needs-based still present in the system > > AFAIK RFC2050 still is in effect. > > All more recent suggestions to get it modified or retired were not successful. > > I got to understand that messing around with it [c|w]ould have far-reaching > unwanted consequences for the whole IP Address Distribution System. Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly fundamental consequences for the environment in which we operate, and at least one of the pillars of RFC2050 ("conservation") is not exactly relevant anymore. I consider RFC2050 a very useful document to establish principles, but it can not be binding - and in doubt, the bottom-up community based process will win. Gert Doering ????????-- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG????????????????????????Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14??????????Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen?????????????????? HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444????????????USt-IdNr.: DE813185279 [1] http://www.leadertelecom.nl/ [2] http://www.GetWildcard.com/nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon Oct 15 16:01:29 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 15 Oct 2012 15:01:29 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Last Call for Comments on Draft Document for Reverse Delegation Policy ripe-302 In-Reply-To: <50780B59.6040404@ripe.net> References: <50780B59.6040404@ripe.net> Message-ID: <507C1739.7030209@inex.ie> On 12/10/2012 13:21, Emilio Madaio wrote: > We encourage you to read this merged version. Please send any comments > to address-policy-wg at ripe.net by 26 October 2012. I'm in favour of this update. Nick From poty at iiat.ru Mon Oct 15 17:17:03 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 15 Oct 2012 19:17:03 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses Message-ID: >> I think you mix LIRs with ISPs. If your company need IPs why you need sub-allocations? > We LIR. We need sub-allocation to allocate IP-networks to our clients (ISP). You are not the only LIR! >>You just ask any LIR and get what you want then. If your client needs IPs and your company does not have the IPs ? the client ask any LIR (which may be not connected, licensed by local authority and has pure distributing business) and get what it want. It does not mean you can?t serve the client with the address space (routing, connectivity?). Why the client has to pay for your mediation and not use LIR?s mechanism created just for that (distribution of IPs)? >We specialised on IPs. Just one of the best service regards IP addresses. Fast and good price. This is reason why ISP goes to us and work with us. I?m not sure that you are right. My company is also a LIR and serve our customers without problems. In Russia there a a lot of LIRs and I don?t think you are the only ?right? and ?kind? company on the market. >Often LIRs which have free space doesn't have people or sales or something another to provide this IPs. They will give us this work. Very simplified and rare situation. Then ? why pay for being LIR? >>If you know more ?cases? explaining the need for your offer ? please list them here. Your ?special case? is just very special to overcome much more ?common? cases. >What special do you see in using IP space by another LIR? I just see in nearest future. While people have demand and we can make rules and regulate it. Or think that market not exist and we will see what happend... Because LIR is not for using ? it is for distributing! Market, market? I?m not afraid of market ? we are living in market all life. My question was about transfers and ? the thing which Russian company loves well ?long chains of companies reselling the single product with constantly increased cost. We have RIR->LIR distribution. We have LIR->end user distribution. I think it is enough! >> I see one more obstacle for lifting the ?need-based criteria?. If the IPs become assets > >you will have to pay different taxation in your own country (up to now RIPE NCC > >made very serious efforts to explain to authorities in different countries that IPs are > >not assets). And then the $10 for IP you mentioned will be fantastic deal (at least > >in Russia)! >No-no. It is different question. IPs are not assets. You are right. It?s the same question! Because as soon as we speak about market ? we sell or buy some assets or services on it. Regards, Vladislav Potapov IIAT, Ltd. URL: http://www.LeaderTelecom.nl/ - IP- addresses URL: http://www.GetWildcard.com/nl - WildCard SSL certificates 15.10.2012 14:31 - ???????(?): Dear Alexey, I think you mix LIRs with ISPs. If your company need IPs why you need sub-allocations? You just ask any LIR and get what you want then. If your client needs IPs and your company does not have the IPs ? the client ask any LIR (which may be not connected, licensed by local authority and has pure distributing business) and get what it want. It does not mean you can?t serve the client with the address space (routing, connectivity?). Why the client has to pay for your mediation and not use LIR?s mechanism created just for that (distribution of IPs)? If you know more ?cases? explaining the need for your offer ? please list them here. Your ?special case? is just very special to overcome much more ?common? cases. I see one more obstacle for lifting the ?need-based criteria?. If the IPs become assets you will have to pay different taxation in your own country (up to now RIPE NCC made very serious efforts to explain to authorities in different countries that IPs are not assets). And then the $10 for IP you mentioned will be fantastic deal (at least in Russia)! Regards, Vladislav Potapov IIAT, Ltd. From: LeaderTelecom B.V. [mailto:info at leadertelecom.nl] Sent: Thursday, October 11, 2012 3:56 PM To: Potapov Vladislav Cc: address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear Vladislav, It is not just "may". It is real case. Permanenent transfer cost 10USD per 1 IP. It is too high. We won't pay this money. We ready pay monthly. It this case the best way to give legal IPs for us - make "sub allocation". But we have restricion in policy - another LIR can sub-allocate only /20 every twelve months. This is too small size. While we need assign now in several times more. And as soon as we will assign this space - we will receive additional requests, but the same supplier by current policy can't give us additional networks while he can do it only one time in twelve months. About "may" - it was an example when can be sub-allocated all space. While Gert Doering wrote about this case. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 14:51 - ???????(?): And for this very special ?may? we should treat the whole existing idea as obsolete? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat From: LeaderTelecom B.V. [mailto:info at leadertelecom.nl ] Sent: Thursday, October 11, 2012 2:35 PM To: Potapov Vladislav Cc: address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear Vladislav, It is just one case. Anyway may be some company started big telecom project which was paused and they have IPs which they can't use in this moment. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 12:37 - ???????(?): >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Oct 15 18:04:39 2012 From: randy at psg.com (Randy Bush) Date: Mon, 15 Oct 2012 06:04:39 -1000 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350294150.928083.716054219.241366.2@otrs.hostingconsult.ru> References: <1349956543.727327.229714196.241366.2@otrs.hostingconsult.ru> <1350216364.374202.373199173.241366.2@otrs.hostingconsult.ru> <1350294150.928083.716054219.241366.2@otrs.hostingconsult.ru> Message-ID: >> i have given multi-year loans, admittedly not transfers as they did not >> exist at the time, a number of times.??i have space out on loan now. > > What records did you use for that? I mean "Assigned PA", > "Sub-allocated PA", etc? And how many IPs? as the space is not in the ripe region, with 39 flavors of integers, your question is not answerable. randy From sergey at devnull.ru Mon Oct 15 19:45:13 2012 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 15 Oct 2012 19:45:13 +0200 Subject: [address-policy-wg] [ncc-services-wg] [policy-announce] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <20121015152726.GA41549@cilantro.c4inet.net> References: <507c1445.c3b20e0a.45bd.336dSMTPIN_ADDED@mx.google.com> <20121015152726.GA41549@cilantro.c4inet.net> Message-ID: <61720712.20121015194513@devnull.ru> I also disagree with the statement 'detect and react'. Sponsoring LIR is not responsible for the PI network and often does not provide any kind of IP connectivity. There is an existence of valid PI contacts listed as one of criteria for PI assignment. And this is enough. Monday, October 15, 2012, 5:27:26 PM, you wrote: SL> On Mon, Oct 15, 2012 at 04:23:56PM +0200, Richard Hartmann wrote: >>This could help curb, or at least detect and react to, abuse once IPv4 >>PI is hopefully allowed once again. SL> That is exactly why I strongly oppose this proposal. Publishing the SL> sponsoring LIR for a PI assignment creates an appearance of SL> responsibility on the part of the sposoring LIR, for the actions of the SL> PI assignee, *that does not exist*. -- Sergey From info at leadertelecom.nl Tue Oct 16 14:17:30 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Tue, 16 Oct 2012 16:17:30 +0400 Subject: [address-policy-wg] [Ticket#2012101501001508] [ncc-services-wg] [policy-announce] 2012-08 New Policy Proposal (Publication of [...] In-Reply-To: <61720712.20121015194513@devnull.ru> References: <61720712.20121015194513@devnull.ru><507c1445.c3b20e0a.45bd.336dSMTPIN_ADDED@mx.google.com> <20121015152726.GA41549@cilantro.c4inet.net> Message-ID: <1350389850.664205.190305369.253964.2@otrs.hostingconsult.ru> Dear?Sergey, I agree with Sergey. Every time when we have any troubles with PI-networks - we are receiving answer that end-user fully responsible for this IPs and LIR can't do anything with this resources. So doesn't make sense to show who is sponsoring LIR. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 15.10.2012 21:52 - Sergey Myasoedov ???????(?): I also disagree with the statement 'detect and react'. Sponsoring LIR is not responsible for the PI network and often does not provide any kind of IP connectivity. There is an existence of valid PI contacts listed as one of criteria for PI assignment. And this is enough. Monday, October 15, 2012, 5:27:26 PM, you wrote: SL> On Mon, Oct 15, 2012 at 04:23:56PM +0200, Richard Hartmann wrote: >>This could help curb, or at least detect and react to, abuse once IPv4 >>PI is hopefully allowed once again. SL> That is exactly why I strongly oppose this proposal. Publishing the SL> sponsoring LIR for a PI assignment creates an appearance of SL> responsibility on the part of the sposoring LIR, for the actions of the SL> PI assignee, *that does not exist*. -- Sergey -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.nl Tue Oct 16 14:23:25 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Tue, 16 Oct 2012 16:23:25 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: References: Message-ID: <1350390205.140632.48695898.241366.2@otrs.hostingconsult.ru> Dear?Vladislav, > >We specialised on IPs. Just one of the best service regards IP addresses. Fast and good price. > > This is reason why ISP goes to us and work with us. ? > I?m not sure that you are right. My company is also a LIR and serve our customers > without problems. In Russia there a a lot of LIRs and I don?t think you are the > only ?right? and ?kind? company on the market. We very specialised company. We kind in niche in Russia. As I calculated we are 2-nd by size LIR by count of sponsored PI-networks, for example.? > >Often LIRs which have free space doesn't have people or sales or something another to provide > this Ps.?They will give us this work.? > Very simplified and rare situation. Then ? why pay for being LIR? While main business in telecom. And they wont sell IPs. Just ask LIRs - who can provide IPs? >>If you know more ?cases? explaining the need for your offer ? please list them here. Your ?special case? is just very special to overcome much more ?common? cases. >What special do you see in using IP space by another LIR??I just see in nearest future. While people have?demand and we can make rules and regulate it. Or think that market not exist and we will see what happend... Because LIR is not for using ? it is for distributing! Market, market? I?m not afraid of market ? we are living in market all life. My question was about transfers and ? the thing which Russian company loves well ?long chains of companies reselling the single product with constantly increased cost. We have RIR->LIR distribution. We have LIR->end user distribution. I think it is enough! No, not enought. IPs will be reselled, but without registration in RIPE. Would you like it? I think better give instrument for comunity for simple distribution IPv4. In other cases you can forget about whois. If it will be impossible to register changes - then you will see old information. >>?I see one more obstacle for? lifting the ?need-based criteria?. If the IPs become assets >?>you will have to pay different taxation in your own country (up to now RIPE NCC >?>made very serious efforts to explain to authorities in different countries that IPs are >?>not assets). And then the $10 for IP you mentioned will be fantastic deal (at least >?>in Russia)! >No-no. It is different question. IPs are not assets. You are right. It?s the same question! Because as soon as we speak about market ? we sell or buy some assets or services on it. Ok. But what about current transfers? -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team URL: [1]http://www.LeaderTelecom.nl/?-?IP- addresses URL: [2]http://www.GetWildcard.com/nl?- WildCard SSL certificates 15.10.2012 19:17 - ???????(?): >> I think you mix LIRs with ISPs. If your company need IPs why you need sub-allocations? > We LIR. We need sub-allocation to allocate IP-networks to our clients (ISP). ? You are not the only LIR! ? >>You just ask any LIR and get what you want then. If your client needs IPs and your company does not have the IPs ? the client ask any LIR (which may be not connected, licensed by local authority and has pure distributing business) and get what it want. It does not mean you can?t serve the client with the address space (routing, connectivity?). Why the client has to pay for your mediation and not use LIR?s mechanism created just for that (distribution of IPs)? >We specialised on IPs. Just one of the best service regards IP addresses. Fast and good price. This is reason why ISP goes to us and work with us. ? I?m not sure that you are right. My company is also a LIR and serve our customers without problems. In Russia there a a lot of LIRs and I don?t think you are the only ?right? and ?kind? company on the market. >Often LIRs which have free space doesn't have people or sales or something another to provide this IPs. They will give us this work.? Very simplified and rare situation. Then ? why pay for being LIR? >>If you know more ?cases? explaining the need for your offer ? please list them here. Your ?special case? is just very special to overcome much more ?common? cases. >What special do you see in using IP space by another LIR? I just see in nearest future. While people have?demand and we can make rules and regulate it. Or think that market not exist and we will see what happend... Because LIR is not for using ? it is for distributing! Market, market? I?m not afraid of market ? we are living in market all life. My question was about transfers and ? the thing which Russian company loves well ?long chains of companies reselling the single product with constantly increased cost. We have RIR->LIR distribution. We have LIR->end user distribution. I think it is enough! >> I see one more obstacle for? lifting the ?need-based criteria?. If the IPs become assets > >you will have to pay different taxation in your own country (up to now RIPE NCC > >made very serious efforts to explain to authorities in different countries that IPs are > >not assets). And then the $10 for IP you mentioned will be fantastic deal (at least > >in Russia)! >No-no. It is different question. IPs are not assets. You are right. It?s the same question! Because as soon as we speak about market ? we sell or buy some assets or services on it. Regards, Vladislav Potapov IIAT, Ltd. URL: [3]http://www.LeaderTelecom.nl/?-?IP- addresses URL: [4]http://www.GetWildcard.com/nl?- WildCard SSL certificates 15.10.2012 14:31 - ???????(?): Dear Alexey, I think you mix LIRs with ISPs. If your company need IPs why you need sub-allocations? You just ask any LIR and get what you want then. If your client needs IPs and your company does not have the IPs ? the client ask any LIR (which may be not connected, licensed by local authority and has pure distributing business) and get what it want. It does not mean you can?t serve the client with the address space (routing, connectivity?). Why the client has to pay for your mediation and not use LIR?s mechanism created just for that (distribution of IPs)? If you know more ?cases? explaining the need for your offer ? please list them here. Your ?special case? is just very special to overcome much more ?common? cases. I see one more obstacle for? lifting the ?need-based criteria?. If the IPs become assets you will have to pay different taxation in your own country (up to now RIPE NCC made very serious efforts to explain to authorities in different countries that IPs are not assets). And then the $10 for IP you mentioned will be fantastic deal (at least in Russia)! Regards, Vladislav Potapov IIAT, Ltd. ? ? From: LeaderTelecom B.V. [[5]mailto:info at leadertelecom.nl] Sent: Thursday, October 11, 2012 3:56 PM To: Potapov Vladislav Cc: [6]address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear?Vladislav, It is not just "may". It is real case.? Permanenent transfer cost 10USD per 1 IP. It is too high. We won't pay this money. We ready pay monthly. It this case the best way to give legal IPs for us - make "sub allocation". But we have restricion in policy - another LIR can sub-allocate only /20?every twelve months. This is too small size. While we need assign now in several times more. And as soon as we will assign this space - we will receive additional requests, but the same supplier by current policy can't give us additional networks while he can do it only one time in twelve months.? About "may" - it was an example when can be sub-allocated all space. While Gert Doering wrote about this case. -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 14:51 - ???????(?): And for this very special ?may? we should treat the whole existing idea as obsolete? ? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat ? From: LeaderTelecom B.V. [[7]mailto:info at leadertelecom.nl] Sent: Thursday, October 11, 2012 2:35 PM To: Potapov Vladislav Cc: [8]address-policy-wg at ripe.net Subject: Re: [Ticket#2012092701011684] [address-policy-wg] FW: Sub-allocations - fast and simple re-using IP-addresses Dear?Vladislav, It is just one case. Anyway may be some company started big telecom project which was paused and they have IPs which they can't use in this moment.? -- Kind regards, Alexey Ivanov LeaderTelecom B.V. Team 11.10.2012 12:37 - ???????(?): >For example, in Russia you need 1,5-2 years from incorporation until receving all permissions (licenses, etc.) >from goverment to provide telecommunication services. In this case company can sub-allocate all space for some time. >Alexey Ivanov ? I think this message is irrelevant (as soon as the new company won?t have much to sub-allocate) and misleading in the terms of time margins for beginners. ? Regards, Vladislav Potapov IIAT, Ltd. Ru.iiat [1] http://www.leadertelecom.nl/ [2] http://www.GetWildcard.com/nl [3] http://www.leadertelecom.nl/ [4] http://www.GetWildcard.com/nl [5] mailto:info at leadertelecom.nl [6] mailto:address-policy-wg at ripe.net [7] mailto:info at leadertelecom.nl [8] mailto:address-policy-wg at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Tue Oct 16 17:21:51 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 16 Oct 2012 17:21:51 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> References: <20121011134551.GD13776@Space.Net> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> <5076C954.70701@CC.UniVie.ac.at> <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> Message-ID: <507D7B8F.8050200@CC.UniVie.ac.at> LeaderTelecom B.V. wrote: > Dear Gert, > > Agree with your opinion regards RFC 2050. > > Main idea this RFC: This document describes the registry system for the > distribution of globally unique Internet address space and registry > operations. > > Goals: > >>1. Conservation: Fair distribution of globally unique Internet address space > > according to the > >>operational needs of the end-users and Internet Service Providers operating > > networks using this > >>address space. Prevention of stockpiling in order to maximize the lifetime > > of the Internet address > >>space. > > > This doesn't required anymore. While RIPE doesn't have free space for > distributing. I am sorry, but this is simply wrong. The NCC still *does* have addresses (Ipv4) to distribute. that's the reason for having all the "Last /8" stuff (an the bickering :-) ) There's also the provision for the IANA to re-distribute address blockas to the RIRs, that get returned. > It was very useful before and respect for people who wrote it while principes > in this RFC were very useful long time. IMHO, they are still as appropriate now as they were from the beginning. > But for now it looks as deprecated and > not updated. I do agree with regard to the "not updated". Anyone is free to start the process of updating or replacing an RFC, though. > Some words from RFC which looks like depriceated: > > ...Currently there are three regional IRs established; > InterNIC serving North America, RIPE NCC serving Europe, and AP- > NIC serving the Asian Pacific region... > > ...3.2 Network Engineering Plans.. > > 2. a description of the network topology > > 3. a description of the network routing plans, including the > routing protocols to be used as well as any limitations.. > > -- > Kind regards, > Alexey Ivanov > LeaderTelecom B.V. Team > > URL: [1]http://www.LeaderTelecom.nl/ - IP- addresses > URL: [2]http://www.GetWildcard.com/nl - WildCard SSL certificates > > 11.10.2012 17:46 - Gert Doering ???????(?): > Hi, > > On Thu, Oct 11, 2012 at 03:27:48PM +0200, Wilfried Woeber wrote: > >>Gert Doering wrote: >> >>[...] >> >>>There are traces of needs-based still present in the system >> >>AFAIK RFC2050 still is in effect. >> >>All more recent suggestions to get it modified or retired were not > > successful. > >>I got to understand that messing around with it [c|w]ould have far-reaching >>unwanted consequences for the whole IP Address Distribution System. > > > Like we have Addresses to Distribute :-) - the IPv4 run-out has fairly > fundamental consequences for the environment in which we operate, and > at least one of the pillars of RFC2050 ("conservation") is not exactly > relevant anymore. I disagrre. If your statement would be true, then we wouldn't need the L/8 stuff to begin with. The community seems to (still) think otherwise. > I consider RFC2050 a very useful document to establish principles, but it > can not be binding - and in doubt, the bottom-up community based process > will win. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 Wilfried From drc at virtualized.org Tue Oct 16 19:08:35 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 16 Oct 2012 13:08:35 -0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> References: <20121011134551.GD13776@Space.Net> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> <5076C954.70701@CC.UniVie.ac.at> <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> Message-ID: <8399988F-7EC5-453A-A24A-6F4F7062366F@virtualized.org> Alexey, On Oct 15, 2012, at 5:59 AM, LeaderTelecom B.V. wrote: > But for now it looks as deprecated and not updated. RFC 2050 was intended to document the then-current (1996) number registry policies. As mentioned in the IESG-inserted prologue, the IESG was going to reevaluate the "best current practice" status via the Internet Registry Evolution (IRE) working group (which never got beyond the BOF stage). By the time 2050 was published, it was already overtaken by events and I believe there was a consensus (at least within the RIR and maybe network operation communities) that further policy definition should be done within the RIR structures, not the IETF. As such, I've always found folks treating 2050 as holy text somewhat amusing. I have suggested in a couple of places that 2050 should be moved to Historic, but there doesn't seem much appetite in the IETF to take that on. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Oct 16 20:13:43 2012 From: randy at psg.com (Randy Bush) Date: Tue, 16 Oct 2012 08:13:43 -1000 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <8399988F-7EC5-453A-A24A-6F4F7062366F@virtualized.org> References: <20121011134551.GD13776@Space.Net> <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> <1349274066.9582.61568373962.241366.2@otrs.hostingconsult.ru> <1349735628.268203.58625248.241366.2@otrs.hostingconsult.ru> <20121009090306.GM13776@Space.Net> <5073F978.3030304@redpill-linpro.com> <20121009121151.GO13776@Space.Net> <5076C954.70701@CC.UniVie.ac.at> <1350295165.571172.093541479.241366.2@otrs.hostingconsult.ru> <8399988F-7EC5-453A-A24A-6F4F7062366F@virtualized.org> Message-ID: > RFC 2050 was intended to document the then-current (1996) number > registry policies. As mentioned in the IESG-inserted prologue, the > IESG was going to reevaluate the "best current practice" status via > the Internet Registry Evolution (IRE) working group (which never got > beyond the BOF stage). By the time 2050 was published, it was already > overtaken by events and I believe there was a consensus (at least > within the RIR and maybe network operation communities) that further > policy definition should be done within the RIR structures, not the > IETF. > > As such, I've always found folks treating 2050 as holy text somewhat > amusing. I have suggested in a couple of places that 2050 should be > moved to Historic, but there doesn't seem much appetite in the IETF to > take that on. amusingly, it is held up as sacred text when it suits, and described as ancient history when it does not suit. but the admin infrastructure seems to have majored in hypocrisy, so no shock there. we were both there in danvers, as were others. it was a meeting of the ops and the then-existent rirs to reach some agreements, especially on allocation size and satanic phyltres (the /19 compromise). in normal ops behavior, once the immediate deal was done, we all went back to work and forgot about it. the rirs used it to embed self-perpetuating monopolies. today's problem is that reaching a new agreement would mean slicing through massive rhetoric, bs, deeply embedded financial positions in rental of integers, vigilante culture, ... that it is essentially hopeless. otoh, i must compliment the ripe community for trying to address the issues of legacy, pi, ... space, and re-form the internet community. maybe there is hope. randy From poty at iiat.ru Wed Oct 17 13:01:37 2012 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 17 Oct 2012 15:01:37 +0400 Subject: [address-policy-wg] FW: [Ticket#2012092701011684] FW: Sub-allocations - fast and simple re-using IP-addresses Message-ID: Hello, We very specialised company. We kind in niche in Russia. As I calculated we are 2-nd by size LIR by count of sponsored PI-networks, for example. So, it?s only small number of companies need this changes? > >Often LIRs which have free space doesn't have people or sales or something another to provide > this Ps. They will give us this work. > Very simplified and rare situation. Then ? why pay for being LIR? While main business in telecom. And they wont sell IPs. Just ask LIRs - who can provide IPs? I?ve already answered your last question. According to the initial provisions: if a LIR doesn?t have people, or salespersons, or wishes, or time, or everything else to distribute IPs ?then I?m in doubt the company will got the abovementioned things to bother to suballocate. My question was about transfers and ? the thing which Russian company loves well ?long chains of companies reselling the single product with constantly increased cost. We have RIR->LIR distribution. We have LIR->end user distribution. I think it is enough! No, not enought. IPs will be reselled, but without registration in RIPE. Would you like it? I think better give instrument for comunity for simple distribution IPv4. In other cases you can forget about whois. If it will be impossible to register changes - then you will see old information. It is possible to register changes. It will be possible to register changes. Reselling without registering to RIPE would led to dealing with all network problems by registered company, which is not very productive in the modern black-and-white listing world. By the way ? now (I know that very well) there are several companies that already use this cheating (for several reasons) and they did this thing for several years to now even at that time (when they began) there was no IP exhaustion. And what? The RIR-LIR-EU system is here and works well. >> ? If the IPs become assets > >you will have to pay different taxation in your own country >No-no. It is different question. IPs are not assets. You are right. It?s the same question! Because as soon as we speak about market ? we sell or buy some assets or services on it. Ok. But what about current transfers? They are ?needs based? and you pay for service (mostly once). Regards, Vladislav -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej.sury at nic.cz Thu Oct 18 13:59:40 2012 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 18 Oct 2012 13:59:40 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) References: <76924001433123110614095@BleauHausXPS> Message-ID: <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> Hi, seems like it has begun... :( (I don't probably need to remind here on this list, that this behavior is against the RIPE policy...) I personally (no hat) would propose that RIPE performs an discreet investigation, asking for references (as in "References from our many existing lessor companies are available upon request.") and returning those blocks into the pool when abuse is detected. Regards, Ondrej Sury Begin forwarded message: > From: "IP Brokerage" > Subject: IP Broker for -1.-1.-1.-1 > Date: 17. ??jna 2012 18:52:24 GMT+02:00 > Reply-To: info at xxx > > Confidential For: XXXXXXXXX > > We are contacting you to participate in a bidding process for the lease or potential sale of IPv4 address space. IPv4 is transitioning and will soon be replaced by IPv6. We encourage you to take this opportunity to monetize your IPv4 assets before they become obsolete. > > RxxxMxxxxx_IP is currently seeking to enter into direct lease agreements for large netblocks of currently unused IP space. We pay market lease rates via wire transfer and are accustomed to closing transactions quickly. Our lease of your IP space will be governed by a customary Service Level Agreement (SLA) and no abusive practices will be permitted or tolerated. References from our many existing lessor companies are available upon request. > > Leasing your excess IPv4 space allows you to generate income, while retaining ownership of your IPv4 allocations for future use or ultimate sale. > > If your organization (XXXXXXXX) has an underperforming IPv4 subnet, such as -1.-1.-1.-1 or some other range of any size, and you are interested in monetizing this asset immediately, for any duration or terms, please contact me or complete the RFP (request for proposal) questionnaire below and return it to my attention at info at xxxxxx. > > Thank you for your participation in our RFP process, and please do not hesitate to contact me if you have any questions. > > I am interested in monetizing my IPv4 Assets: > > > Company Name: > Size or number of IPs available for lease: > Identify Range (CIDR): > email: > Phone number: > Proposed start date for lease: > > > RxxxMxxxx_IP is also actively engaged in buying and selling IP address space. Please let us know if this is of interest to you as well. > > John Blank > Business Development > RxxxMxxxxx_IP > Of . xxx.xxx.xxx > Sk . xxxxxx > -- Ond?ej Sur? -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4150 bytes Desc: not available URL: From gert at space.net Thu Oct 18 15:43:12 2012 From: gert at space.net (Gert Doering) Date: Thu, 18 Oct 2012 15:43:12 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> Message-ID: <20121018134312.GC13776@Space.Net> Hi, On Thu, Oct 18, 2012 at 01:59:40PM +0200, Ond??ej Sur? wrote: > seems like it has begun... :( > > (I don't probably need to remind here on this list, that this behavior is against the RIPE policy...) Is it? > I personally (no hat) would propose that RIPE performs an discreet > investigation, asking for references (as in "References from our > many existing lessor companies are available upon request.") and > returning those blocks into the pool when abuse is detected. Transferring address blocks to those in need and receiving monetary compensation in exchange is *not* against RIPE policies. To the contrary, it is expected that the transfers are registered with the RIPE NCC so people know who currently "owns"(*) an address block. Gert Doering -- APWG chair (*) "holds the right to use it" -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7650 bytes Desc: not available URL: From ondrej.sury at nic.cz Thu Oct 18 15:45:01 2012 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 18 Oct 2012 15:45:01 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: <20121018134312.GC13776@Space.Net> References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> <20121018134312.GC13776@Space.Net> Message-ID: Hi, On 18. 10. 2012, at 15:43, Gert Doering wrote: > Hi, > > On Thu, Oct 18, 2012 at 01:59:40PM +0200, Ond??ej Sur? wrote: >> seems like it has begun... :( >> >> (I don't probably need to remind here on this list, that this behavior is against the RIPE policy...) > > Is it? > >> I personally (no hat) would propose that RIPE performs an discreet >> investigation, asking for references (as in "References from our >> many existing lessor companies are available upon request.") and >> returning those blocks into the pool when abuse is detected. > > Transferring address blocks to those in need and receiving monetary > compensation in exchange is *not* against RIPE policies. > > To the contrary, it is expected that the transfers are registered with > the RIPE NCC so people know who currently "owns"(*) an address block. The email/proposition talks about "leases", and not transfers. And if I remember correctly you should return unused blocks and not lease them, don't you? O. > Gert Doering > -- APWG chair > > (*) "holds the right to use it" > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -- Ond?ej Sur? -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4150 bytes Desc: not available URL: From gert at space.net Thu Oct 18 15:48:10 2012 From: gert at space.net (Gert Doering) Date: Thu, 18 Oct 2012 15:48:10 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> <20121018134312.GC13776@Space.Net> Message-ID: <20121018134810.GD13776@Space.Net> Hi, On Thu, Oct 18, 2012 at 03:45:01PM +0200, Ond??ej Sur? wrote: > > Transferring address blocks to those in need and receiving monetary > > compensation in exchange is *not* against RIPE policies. > > > > To the contrary, it is expected that the transfers are registered with > > the RIPE NCC so people know who currently "owns"(*) an address block. > > The email/proposition talks about "leases", and not transfers. Transfers can be temporary. > And if I remember correctly you should return unused blocks and not > lease them, don't you? You are certainly welcome to return unsed blocks to the RIPE NCC, but you do not *have* to - the policies for allocations do not require that (and there is no provision for the NCC to forcibly take them back either), that's only for assignments. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7650 bytes Desc: not available URL: From ondrej.sury at nic.cz Thu Oct 18 16:08:03 2012 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 18 Oct 2012 16:08:03 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: <20121018134810.GD13776@Space.Net> References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> <20121018134312.GC13776@Space.Net> <20121018134810.GD13776@Space.Net> Message-ID: <7C4F6D8A-9CDB-4351-ADCA-EFA9C2B50C84@nic.cz> Hi Gert, On 18. 10. 2012, at 15:48, Gert Doering wrote: > Hi, > > On Thu, Oct 18, 2012 at 03:45:01PM +0200, Ond??ej Sur? wrote: >>> Transferring address blocks to those in need and receiving monetary >>> compensation in exchange is *not* against RIPE policies. >>> >>> To the contrary, it is expected that the transfers are registered with >>> the RIPE NCC so people know who currently "owns"(*) an address block. >> >> The email/proposition talks about "leases", and not transfers. > > Transfers can be temporary. I see nothing about temporary transfers in 5.5 of IPv5 policy. The leases would best fit under "sub-allocations", but that's just for downstream network operators (and I read that as BGP downstreams, not a random entity on the net). Also the transfers has to be approved by RIPE NCC, so you cannot ensure it's "temporary", because you can be denied the transfer-back. Correct me if I read the policy in a wrong way. >> And if I remember correctly you should return unused blocks and not >> lease them, don't you? > > You are certainly welcome to return unsed blocks to the RIPE NCC, but > you do not *have* to - the policies for allocations do not require that > (and there is no provision for the NCC to forcibly take them back either), > that's only for assignments. True, that was just my thinking about being a good "netizen", but it's not covered in the policy. Anyway I still think the leases are not in the line with the current policy. O. -- Ond?ej Sur? -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4150 bytes Desc: not available URL: From sander at steffann.nl Thu Oct 18 16:34:07 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 18 Oct 2012 16:34:07 +0200 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: <7C4F6D8A-9CDB-4351-ADCA-EFA9C2B50C84@nic.cz> References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> <20121018134312.GC13776@Space.Net> <20121018134810.GD13776@Space.Net> <7C4F6D8A-9CDB-4351-ADCA-EFA9C2B50C84@nic.cz> Message-ID: Hi Ond?ej, > I see nothing about temporary transfers in 5.5 of IPv5 policy. It's in the third paragraph: 'Re-allocation must be reflected in the RIPE Database. This re-allocation may be on either a permanent or non-permanent basis.' > The leases would best fit under "sub-allocations", but that's just for downstream network operators (and I read that as BGP downstreams, not a random entity on the net). That is exactly what Alexey Ivanov (LeaderTelecom) is discussing on this very list. > Also the transfers has to be approved by RIPE NCC, so you cannot ensure it's "temporary", because you can be denied the transfer-back. No, handing back the addresses to the original holder is not a separate transfer. It's just the end of the original transfer. > Correct me if I read the policy in a wrong way. I hope I have :-) > True, that was just my thinking about being a good "netizen", but it's not covered in the policy. > > Anyway I still think the leases are not in the line with the current policy. Using the label 'lease' might be a but confusing, but if they use the transfer policy with a temporary transfer it does fit. It would be helpful to have consistent naming for these things though. Met vriendelijke groet, Sander Steffann From mueller at syr.edu Thu Oct 18 21:47:57 2012 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 18 Oct 2012 19:47:57 +0000 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> Message-ID: <855077AC3D7A7147A7570370CA01ECD2267FC7@SUEX10-mbx-10.ad.syr.edu> From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Ondrej Sur? (I don't probably need to remind here on this list, that this behavior is against the RIPE policy...) [Milton L Mueller] should it be? -------------- next part -------------- An HTML attachment was scrubbed... URL: From presiden at ukraine.su Fri Oct 19 02:31:19 2012 From: presiden at ukraine.su (Max Tulyev) Date: Fri, 19 Oct 2012 03:31:19 +0300 Subject: [address-policy-wg] [ncc-services-wg] [policy-announce] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <61720712.20121015194513@devnull.ru> References: <507c1445.c3b20e0a.45bd.336dSMTPIN_ADDED@mx.google.com> <20121015152726.GA41549@cilantro.c4inet.net> <61720712.20121015194513@devnull.ru> Message-ID: <74FFFBF3-44AD-47A9-BFCB-B53423DC4EFE@ukraine.su> I agree with Sergey. Sponsoring LIR can't do anything with PI net, i.e. this publication can't help to stop spam from this net, for example. But it can get harm to the business as shows the link to clients, number of it, rough income, etc. Maybe it is good for EU, but definitely NOT good for ex-USSR countries. On 15. 10. 2012, at 20:45, Sergey Myasoedov wrote: > > I also disagree with the statement 'detect and react'. Sponsoring LIR is not responsible > for the PI network and often does not provide any kind of IP connectivity. > > There is an existence of valid PI contacts listed as one of criteria for PI assignment. > And this is enough. > > > > Monday, October 15, 2012, 5:27:26 PM, you wrote: > > SL> On Mon, Oct 15, 2012 at 04:23:56PM +0200, Richard Hartmann wrote: >>> This could help curb, or at least detect and react to, abuse once IPv4 >>> PI is hopefully allowed once again. > SL> That is exactly why I strongly oppose this proposal. Publishing the > SL> sponsoring LIR for a PI assignment creates an appearance of > SL> responsibility on the part of the sposoring LIR, for the actions of the > SL> PI assignee, *that does not exist*. > > > > -- > Sergey > > From jcurran at arin.net Fri Oct 19 13:34:33 2012 From: jcurran at arin.net (John Curran) Date: Fri, 19 Oct 2012 11:34:33 +0000 Subject: [address-policy-wg] Seen this?: (Was: IP Broker for -1.-1.-1.-1) In-Reply-To: References: <76924001433123110614095@BleauHausXPS> <384900CA-25A4-4380-989D-01BA0B9AB963@nic.cz> <20121018134312.GC13776@Space.Net> <20121018134810.GD13776@Space.Net> <7C4F6D8A-9CDB-4351-ADCA-EFA9C2B50C84@nic.cz> Message-ID: <9185FC1D-880D-47EB-882A-C5ECD412DC00@corp.arin.net> On Oct 18, 2012, at 10:34 AM, Sander Steffann wrote: > ... >> True, that was just my thinking about being a good "netizen", but it's not covered in the policy. >> >> Anyway I still think the leases are not in the line with the current policy. > > Using the label 'lease' might be a but confusing, but if they use the transfer policy with a temporary transfer it does fit. It would be helpful to have consistent naming for these things though. Just FYI - In the ARIN region, this issue is presently undefined, i.e. the current policy manual does not take a position either way with regards to subassignments of IP addresses to another party on a temporary basis and/or independent of network services. New address space is issued based on stated plans that it be used for network service customers (if an ISP) or one's own network (if an end-user), but that only applies to issuance of new resources in good faith - there has not been any policy development which establishing clear requirements in this area for existing address holders. See attached email for specifics; I have no view in the discussion of this topic in the RIPE region but provide this only as a data point that may be of interest. FYI, /John John Curran President and CEO ARIN Begin forwarded message: > From: John Curran > Subject: [arin-ppml] Leasing (was: Re: IPv4 Update) > Date: August 22, 2012 9:18:33 PM EDT > To: Enrique Garcia > Cc: "arin-ppml at arin.net" > > On Aug 22, 2012, at 9:58 AM, Enrique Garcia wrote: > >> I received an e-mail this morning from a company claiming that IP Space can now be leased. >> >> Was just wondering if this was legal. > > Enrique - > > If by "legal", you mean "in compliance with the community number resource > management policy in this region", then perhaps I can provide some insight. > > Internet service providers routinely provide IP address assignments as part > of their Internet services bundle, and those assignments are not permanent > in nature but only for the duration of the service agreement. Many would > consider such assignments to be "leased IP address space". > > Organizations receiving IP address space (as the recipient of a transfer or > via allocations of IP address space from the free pool) as an ISP must meet > the LIR definition (per NRPM 2.4) and that means "primarily assigning address > space to the users of the network services that it provides." End-users > receiving transfers or assignments of IP address space from the free pool > must meet the End-user definition (per NRPM 2.6) during their request which > requires they be receiving space to be used "exclusively for use in its > operational networks." > > Ergo, the "leasing" of recently received space could reasonably raise > concern about whether the request to ARIN for that space was made with > full sincerity, and organizations would be advised not to request to receive > IP address from the free pool or as the recipient of a transfer if their intent > is to "lease" the space rather then use it for their network service customers > (if an ISP) or use it for their own network (if they applied as an end-user.) > > There has been no policy development specifically regarding leasing as an > appropriate/inappropriate use of held IP address space, so ARIN does not > have a position either way (aside from the case above of insuring that > requests to receive additional address space are made in good faith based > on existing definitions of usage.) Obviously, individual Internet service > providers may have their own views on handling of "leased" address space, > depending on any number of factors including registrant and block size. > > I hope this helps somewhat in understanding the situation, recognizing > that it is not likely to be as complete an answer as you would have liked. > > Thanks! > /John > > John Curran > President and CEO > ARIN > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Mon Oct 29 16:55:26 2012 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 29 Oct 2012 15:55:26 +0000 Subject: [address-policy-wg] IGF session on IP address policy Message-ID: <855077AC3D7A7147A7570370CA01ECD22759B0@SUEX10-mbx-10.ad.syr.edu> On the afternoon of the first day of the Internet Governance Forum, there will be a workshop on "What is the best response to IPv4 scarcity? Exploring a global transfer market for IPv4 addresses." It will be moderated by myself and Geoff Huston, Chief Scientist at APNIC. There will also be a main session discussion of the topic the next day. The workshop will take a unique format. It will be organized not as a series of panelists speaking _at_ an audience, but as a structured, multi-stakeholder deliberation over policy alternatives among peers. It will test the extent to which the various stakeholders interested in that issue can come to agreement on a set of five basic policy issues affecting IPv4 number resources. The five policy issues we will discuss are: the role of needs assessment in market trades; the status of legacy number block holders; the accuracy of post-transaction records; aggregation policies market power For each of these issues two or three opposing positions are set out, and the workshop will attempt to document who takes which position, why, and whether the group can come to rough consensus on one position or some new compromise position formulated on the spot. The panel is scheduled for 14:30 - 16:00 on 6 November, the first day of the IGF, in Conference Room 9. Although the actual remote participation link for this session has not yet been created by the IGF Secretariat, this page http://www.intgovforum.org/cms/remote-participation provides general information and guidance regarding how the IGF will facilitate remote participation. Baku's time zone is 9 hours ahead of US Eastern time, and 3 hours ahead of Continental European time. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From emadaio at ripe.net Mon Oct 29 16:56:17 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 29 Oct 2012 16:56:17 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) Message-ID: Dear Colleagues, The draft document for the version 2.0 of the proposal 2012-05 has been published. The impact analysis that was conducted for this proposal has also been published. The main changes in the new version are: -use of a bullet point layout for the proposal text; -anonymous reports of non-approved transfers. You can find the full proposal and impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-05 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 12 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From info at leadertelecom.ru Mon Oct 29 19:00:13 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 29 Oct 2012 22:00:13 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: References: Message-ID: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> Dear?Emilio, Thank you for?proposal. I write to oppose the pending proposal to publish a record of all transfers conducted under the policy. For example, on stock market no one publish who sold and who bought shares. I think for safety reason.? For analyse enought anonymous statistical information about transfers. --? Alexey Ivanov LeaderTelecom 29.10.2012 20:27 - Emilio Madaio ???????(?): Dear Colleagues, The draft document for the version 2.0 of the proposal 2012-05 has been published. The impact analysis that was conducted for this proposal has also been published. The main changes in the new version are: -use of a bullet point layout for the proposal text; -anonymous reports of non-approved transfers. You can find the full proposal and impact analysis at: ????[1]https://www.ripe.net/ripe/policies/proposals/2012-05 ???? and the draft document at: ????[2]https://www.ripe.net/ripe/policies/proposals/2012-05/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 12 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC [1] https://www.ripe.net/ripe/policies/proposals/2012-05 [2] https://www.ripe.net/ripe/policies/proposals/2012-05/draft -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Tue Oct 30 10:06:47 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 30 Oct 2012 10:06:47 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <20121029162741.3982EC3AFD@mailhub.linpro.no> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> Message-ID: <508F98A7.6030102@redpill-linpro.com> Hi Alex. I'm under the impression that you're the right guy to ask about this, but please do forward this message if appropriate. Quoting from 2012-05's impact analysis: ?It is worth mentioning that the RIPE NCC is willing to publish details on resource transfers and a report has not been requested so far. Only one transfer has been recorded in the RIPE NCC service region recently, and this is why no details on resource transfers have been published so far.? I'm hereby requesting the details on the transfer mentioned. In particular, I'd like to know the date of the transfer, which specific prefix(es) it involved, and the origin and destination LIRs. I'd like this information in order to try to confirm my belief that this information is possible to extract from the stats files already available on the FTP. Also, if there has been more transfers since the impact analysis was written, I'd like to see their details, as well. If possible, I would prefer to see a daily updated (and easy to parse) text file with all the transfers and their details being made available on the FTP. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From emadaio at ripe.net Tue Oct 30 12:21:50 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 30 Oct 2012 12:21:50 +0100 Subject: [address-policy-wg] DRAFT Mintues from the APWG Meeting at RIPE 65 Message-ID: <508FB84E.8000908@ripe.net> Dear Colleagues, the draft minutes from the APWG sessions at the recent RIPE 65 meeting have been now published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-65 Please let us know if there is anything that needs to be corrected or amended. Best Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Tue Oct 30 15:28:52 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 30 Oct 2012 15:28:52 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') Message-ID: Dear Colleagues, The draft document for the version 2.0 of the policy proposal 2010-06,"Revert 'Run Out Fairly'" has been published. The impact analysis that was conducted for this proposal has also been published. The changes in the version 2.0 are in the Title, Summary and Rationale. They are purely editorial and reflect that the depletion is no longer a future event. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-06 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-06/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 27 November 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From tore.anderson at redpill-linpro.com Tue Oct 30 16:31:11 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 30 Oct 2012 16:31:11 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <20121030143330.15455C39ED@mailhub.linpro.no> References: <20121030143330.15455C39ED@mailhub.linpro.no> Message-ID: <508FF2BF.6040208@redpill-linpro.com> Hi, I invite everyone that supports this proposal to publicly say so by posting a message to the list, so that the proposal will hopefully be fast-tracked by the WG chairs. * Emilio Madaio > The draft document for the version 2.0 of the policy proposal > 2010-06,"Revert 'Run Out Fairly'" has been published. The impact > analysis that was conducted for this proposal has also been > published. I have a small nit to pick with the impact analysis, which says: The allocation and assignment periods will no longer be three months. Said periods will become: [...] - For assignments: 24 months. That is not what the proposal says. It makes no mention of 24 months anywhere. What it does say, is: Assignments? immediate utilisation should be at least 25% of the assigned space. After one year, this should be at least 50% of the space unless special circumstances are defined. Therefore, if the end user's usage is increasing exponentially over time, his maximum assignment period will be less than 24 months. On the other hand, if the end user's usage is increasing at a slower and slower pace over time, his maximum assignment period will be longer than 24 months. In any case, the text in question is the exact same as it used to be before Run Out Fairly was implemented. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Ragnar.Anfinsen at altibox.no Tue Oct 30 21:39:47 2012 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Tue, 30 Oct 2012 20:39:47 +0000 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <508FF2BF.6040208@redpill-linpro.com> Message-ID: I support both the proposal and the suggestion on fast-tracking. +1 /Ragnar On 30.10.12 16:31, "Tore Anderson" wrote: >Hi, > >I invite everyone that supports this proposal to publicly say so by >posting a message to the list, so that the proposal will hopefully be >fast-tracked by the WG chairs. > >* Emilio Madaio > >> The draft document for the version 2.0 of the policy proposal >> 2010-06,"Revert 'Run Out Fairly'" has been published. The impact >> analysis that was conducted for this proposal has also been >> published. > >I have a small nit to pick with the impact analysis, which says: > > The allocation and assignment periods will no longer be three months. > Said periods will become: > [...] > - For assignments: 24 months. > >That is not what the proposal says. It makes no mention of 24 months >anywhere. What it does say, is: > > Assignments? immediate utilisation should be at least 25% of the > assigned space. After one year, this should be at least 50% of the > space unless special circumstances are defined. > >Therefore, if the end user's usage is increasing exponentially over >time, his maximum assignment period will be less than 24 months. > >On the other hand, if the end user's usage is increasing at a slower and >slower pace over time, his maximum assignment period will be longer than >24 months. > >In any case, the text in question is the exact same as it used to be >before Run Out Fairly was implemented. > >Best regards, >-- >Tore Anderson >Redpill Linpro AS - http://www.redpill-linpro.com > From frettled at gmail.com Wed Oct 31 10:04:03 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 31 Oct 2012 10:04:03 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: References: <508FF2BF.6040208@redpill-linpro.com> Message-ID: On Tue, Oct 30, 2012 at 9:39 PM, Anfinsen, Ragnar < Ragnar.Anfinsen at altibox.no> wrote: > I support both the proposal and the suggestion on fast-tracking. > I also support both the proposal and the suggestion on fast-tracking. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.blessing at despres.co.uk Wed Oct 31 11:40:25 2012 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 31 Oct 2012 10:40:25 +0000 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: <1351679678.841493.719037545.256146.2@otrs.hostingconsult.ru> References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <1351679678.841493.719037545.256146.2@otrs.hostingconsult.ru> Message-ID: On 31 October 2012 10:34, LeaderTelecom Ltd. wrote: >> but the information about the transfers is derivable from the RIPE DB > > Yes, but this database too much ditry information and very difficult analyse > it. If you will secure something - you can place it in safe place, but more > effective way to put it in public with different information :-) So you are agreeing that publishing the information about transfers is a good idea to make it easier to see transfers being made? J -- James Blessing 07989 039 476 From info at leadertelecom.ru Wed Oct 31 11:53:44 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 31 Oct 2012 14:53:44 +0400 Subject: [address-policy-wg] [Ticket#2012102901001081] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Addre [...] In-Reply-To: References: <1351533610.855224.102756405.256146.2@otrs.hostingconsult.ru> <1351679678.841493.719037545.256146.2@otrs.hostingconsult.ru> Message-ID: <1351680823.516912.735702658.256146.2@otrs.hostingconsult.ru> > So you are agreeing that publishing the information about transfers > is?a good idea to make it easier to see transfers being made? I think no. Information in?RIPE DB very difficult to analyse. So in fact most of people will not know about transfer. If company name was changed - may be it was just renaming?company. --? Alexey Ivanov 31.10.2012 14:41 - James Blessing ???????(?): On 31 October 2012 10:34, LeaderTelecom Ltd. wrote: >> but the information about the transfers is derivable from the RIPE DB > > Yes, but this database too much ditry information and very difficult analyse > it. If you will secure something - you can place it in safe place, but more > effective way to put it in public with different information :-) So you are agreeing that publishing the information about transfers is a good idea to make it easier to see transfers being made? J -- James Blessing 07989 039 476 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhe at nosc.ja.net Wed Oct 31 13:55:38 2012 From: rhe at nosc.ja.net (Rob Evans) Date: Wed, 31 Oct 2012 12:55:38 +0000 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <508FF2BF.6040208@redpill-linpro.com> References: <20121030143330.15455C39ED@mailhub.linpro.no> <508FF2BF.6040208@redpill-linpro.com> Message-ID: <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> Hi, > I invite everyone that supports this proposal to publicly say so by > posting a message to the list, so that the proposal will hopefully be > fast-tracked by the WG chairs. I'm a little curious about this mention of 'fast-tracking.' The word 'fast' doesn't, perhaps unsurprisingly, appear anywhere in the PDP. The only opportunity to reduce the time taken for the process is by shrinking the review period, which is listed to last "no more than four weeks." Given the deadline for this period has already been sent for November 27th, I'm not sure what scope there is for 'fast tracking.' :) Cheers, Rob From gert at space.net Wed Oct 31 14:35:23 2012 From: gert at space.net (Gert Doering) Date: Wed, 31 Oct 2012 14:35:23 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> References: <20121030143330.15455C39ED@mailhub.linpro.no> <508FF2BF.6040208@redpill-linpro.com> <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> Message-ID: <20121031133523.GE13776@Space.Net> Hi, On Wed, Oct 31, 2012 at 12:55:38PM +0000, Rob Evans wrote: > The only opportunity to reduce the time taken for the process is > by shrinking the review period, which is listed to last "no more > than four weeks." Given the deadline for this period has already > been sent for November 27th, I'm not sure what scope there is for > 'fast tracking.' :) Well, there is the option of "not going to have another review period" if consensus is clear enough :-) - and that fast-tracks things quite a bit. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sander at steffann.nl Wed Oct 31 14:38:16 2012 From: sander at steffann.nl (Sander Steffann) Date: Wed, 31 Oct 2012 14:38:16 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> References: <20121030143330.15455C39ED@mailhub.linpro.no> <508FF2BF.6040208@redpill-linpro.com> <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> Message-ID: <210D261C-7714-4934-AF07-1EAC1F9A6BA4@steffann.nl> Hi, >> I invite everyone that supports this proposal to publicly say so by >> posting a message to the list, so that the proposal will hopefully be >> fast-tracked by the WG chairs. > > I'm a little curious about this mention of 'fast-tracking.' The word 'fast' doesn't, perhaps unsurprisingly, appear anywhere in the PDP. > > > > The only opportunity to reduce the time taken for the process is by shrinking the review period, which is listed to last "no more than four weeks." Given the deadline for this period has already been sent for November 27th, I'm not sure what scope there is for 'fast tracking.' :) There is no such thing, but as a WG co-chair I do understand the sense/feeling of urgency that it gives :-) We cannot change the schedule of the current PDP phase at this time though. Thank you, Sander From tore.anderson at redpill-linpro.com Wed Oct 31 14:49:15 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 31 Oct 2012 14:49:15 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> References: <20121030143330.15455C39ED@mailhub.linpro.no> <508FF2BF.6040208@redpill-linpro.com> <7D265D80-AD64-4F2F-AEF5-EC6EDAD785E2@nosc.ja.net> Message-ID: <50912C5B.4060906@redpill-linpro.com> * Rob Evans > I'm a little curious about this mention of 'fast-tracking.' The word > 'fast' doesn't, perhaps unsurprisingly, appear anywhere in the PDP. > > > > The only opportunity to reduce the time taken for the process is by > shrinking the review period, which is listed to last "no more than > four weeks." Given the deadline for this period has already been > sent for November 27th, I'm not sure what scope there is for 'fast > tracking.' :) I was referring to Gert's reply to Nina's comment in the APWG session at RIPE65, see https://ripe65.ripe.net/archives/video/110/ and skip to 17:50. In http://www.ripe.net/ripe/policies/policy-development-process-glossary it says that ?the default duration for the review period is four weeks, although the WG Chair can reduce this?, so I was assuming that was what he meant by "fast-track". Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From ggiannou at gmail.com Wed Oct 31 14:50:21 2012 From: ggiannou at gmail.com (George Giannousopoulos) Date: Wed, 31 Oct 2012 15:50:21 +0200 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <508fe53b.c9cf0e0a.7c00.7f5dSMTPIN_ADDED@mx.google.com> References: <508fe53b.c9cf0e0a.7c00.7f5dSMTPIN_ADDED@mx.google.com> Message-ID: Hello all, I agree that the three months limitation has to go.. However, I also believe that the period for allocations and assignments should be equal Best regards On Tue, Oct 30, 2012 at 4:28 PM, Emilio Madaio wrote: > > Dear Colleagues, > > > The draft document for the version 2.0 of the policy proposal > 2010-06,"Revert 'Run Out Fairly'" has been published. The impact > analysis that was conducted for this proposal has also been published. > > The changes in the version 2.0 are in the Title, Summary and > Rationale. They are purely editorial and reflect that the depletion is > no longer a future event. > > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-06/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 27 November 2012. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Wed Oct 31 15:38:50 2012 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 31 Oct 2012 15:38:50 +0100 Subject: [address-policy-wg] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly') In-Reply-To: <508fe53b.09c90e0a.786a.71feSMTPIN_ADDED@mx.google.com> References: <508fe53b.09c90e0a.786a.71feSMTPIN_ADDED@mx.google.com> Message-ID: On Tue, Oct 30, 2012 at 3:28 PM, Emilio Madaio wrote: > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-06/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 27 November 2012. I support the proposal and the "fast-tracking" as discussed by others. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From info at leadertelecom.ru Wed Oct 31 15:58:14 2012 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 31 Oct 2012 18:58:14 +0400 Subject: [address-policy-wg] [Ticket#2012103101001906] 2010-06 New Draft and Impact Analysis Document Published (Revert 'Run Out Fairly [...] In-Reply-To: References: <508fe53b.09c90e0a.786a.71feSMTPIN_ADDED@mx.google.com> Message-ID: <1351695493.55376.8441334075.256574.2@otrs.hostingconsult.ru> I support the proposal and the "fast-tracking". -- Alexey Ivanov 31.10.2012 18:44 - Roger J?rgensen ???????(?): On Tue, Oct 30, 2012 at 3:28 PM, Emilio Madaio wrote: > > You can find the full proposal at: > >???? [1]https://www.ripe.net/ripe/policies/proposals/2012-06 > > and the draft document at: > >???? [2]https://www.ripe.net/ripe/policies/proposals/2012-06/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 27 November 2012. I support the proposal and the "fast-tracking" as discussed by others. -- Roger Jorgensen?????????? | ROJO9-RIPE rogerj at gmail.com??????????| - IPv6 is The Key! [3]http://www.jorgensen.no?? | roger at jorgensen.no ? [1] https://www.ripe.net/ripe/policies/proposals/2012-06 [2] https://www.ripe.net/ripe/policies/proposals/2012-06/draft [3] http://www.jorgensen.no -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexlh at ripe.net Wed Oct 31 16:23:45 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 31 Oct 2012 16:23:45 +0100 Subject: [address-policy-wg] 2012-05 New Draft and Impact Analysis Documents Published (Transparency in Address Block Transfers) In-Reply-To: <508F98A7.6030102@redpill-linpro.com> References: <20121029162741.3982EC3AFD@mailhub.linpro.no> <508F98A7.6030102@redpill-linpro.com> Message-ID: <0F0D5867-B3C9-409C-9419-D6F3A461F11D@ripe.net> Dear Tore, > Quoting from 2012-05's impact analysis: > > ?It is worth mentioning that the RIPE NCC is willing to publish details > on resource transfers and a report has not been requested so far. Only > one transfer has been recorded in the RIPE NCC service region recently, > and this is why no details on resource transfers have been published so > far.? > > I'm hereby requesting the details on the transfer mentioned. In > particular, I'd like to know the date of the transfer, which specific > prefix(es) it involved, and the origin and destination LIRs. I'd like > this information in order to try to confirm my belief that this > information is possible to extract from the stats files already > available on the FTP. > > Also, if there has been more transfers since the impact analysis was > written, I'd like to see their details, as well. If possible, I would > prefer to see a daily updated (and easy to parse) text file with all the > transfers and their details being made available on the FTP. Publishing this information as a daily updated file on our FTP or web site is most likely the format that the RIPE NCC would prefer as well. However, given this proposal and the discussion around it, we would prefer to wait until it reaches a conclusion before publishing. We already publish various files that reflect the state of the RIPE registry: ftp://ftp.ripe.net/pub/stats/ripencc/ ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt ftp://ftp.ripe.net/ripe/dbase/split/ Comparing different versions of these files will show any transfers that were done under the transfer policy. It would however also show the results of the various types of mergers, acquisitions and divestments that also happen on a regular basis. I hope this answers your questions for now. Best regards, Alex Le Heux Policy Implementation and Co-ordination RIPE NCC