From sander at steffann.nl Mon Sep 3 12:28:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 3 Sep 2012 12:28:59 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: References: <20120803123602.2E884200D@mail.sintact.nl> Message-ID: <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> Hello Working Group, Looking at the feedback I see two types of responses: - The policy proposal is good as it is - Information on rejected transfer should be anonymised We could suggest to the proposer to add the 'anonymise rejected transfers' bit to the proposal, but we are not sure if that would gain support on one side while losing support from people who like the policy proposal as it currently is... So... Again your feedback please! Is there anyone who thinks that anonymising details of rejected transfers is a bad idea? (and if so: please explain why) Thank you, Sander Steffann APWG Co-chair From lists-ripe at c4inet.net Mon Sep 3 12:38:37 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 3 Sep 2012 11:38:37 +0100 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> Message-ID: <20120903103837.GA69922@cilantro.c4inet.net> On Mon, Sep 03, 2012 at 12:28:59PM +0200, Sander Steffann wrote: >So... Again your feedback please! Is there anyone who thinks that >anonymising details of rejected transfers is a bad idea? (and if so: >please explain why) I'd go one further and anonymise all transfer data. Who has an operational *need-to-know* this data? rgds, Sascha Luck From emadaio at ripe.net Mon Sep 3 14:18:31 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 03 Sep 2012 14:18:31 +0200 Subject: [address-policy-wg] 2012-05 Review Period extended until 17 September 2012 (Transparency in Address Block Transfers) Message-ID: Dear Colleagues, The Review Period for the proposed change to RIPE Document ripe-553 has been extended until 17 September 2012. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Mon Sep 3 15:50:06 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 03 Sep 2012 15:50:06 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) Message-ID: Dear Colleagues A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-06 We encourage you to review this proposal and send your comments to before 1 October 2012. Regards Emilio Madaio Policy Development Officer RIPE NCC From jan at go6.si Mon Sep 3 16:02:20 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 03 Sep 2012 16:02:20 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <20120903135034.24C5122B40D9@ipv6.go6.si> References: <20120903135034.24C5122B40D9@ipv6.go6.si> Message-ID: <5044B86C.7040803@go6.si> On 9/3/12 3:50 PM, Emilio Madaio wrote: > Dear Colleagues > > A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation > and Assignment Policy for the RIPE NCC Service Region", is now > available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 I see the noble goal of this proposal - but why bother? Do we have even enough time for this proposal to become valid policy change according to all valid rules of PDP? http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph According to this graph we have one month to go. Cheers, Jan Zorz From gert at space.net Mon Sep 3 16:30:28 2012 From: gert at space.net (Gert Doering) Date: Mon, 3 Sep 2012 16:30:28 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <5044B86C.7040803@go6.si> References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> Message-ID: <20120903143028.GQ13776@Space.Net> Hi, On Mon, Sep 03, 2012 at 04:02:20PM +0200, Jan Zorz @ go6.si wrote: > On 9/3/12 3:50 PM, Emilio Madaio wrote: > > Dear Colleagues > > > > A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation > > and Assignment Policy for the RIPE NCC Service Region", is now > > available for discussion. > > > > > > You can find the full proposal at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > I see the noble goal of this proposal - but why bother? Do we have even > enough time for this proposal to become valid policy change according to > all valid rules of PDP? We have all time of the world, as this only affects policy *after* the IPv4 runout :-) (and there's no way to get this through before). This is not really aimed at "RIPE NCC address distribution", but as the RIPE IPv4 address policy also sets the policy for "LIR to end customer address assignment", and the *timelines* for that, it does make a difference. To those LIRs that work operate to policy (which they all sign...), and have some addresses left in stock... 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 ebais at a2b-internet.com Mon Sep 3 17:47:37 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 3 Sep 2012 17:47:37 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <5044B86C.7040803@go6.si> References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> Message-ID: <002b01cd89eb$715220a0$53f661e0$@a2b-internet.com> Hi Jan, > I see the noble goal of this proposal - but why bother? Do we have even enough time for this proposal to become valid policy change according to all valid rules of PDP? > http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-poo l-graph > According to this graph we have one month to go. This would also apply for the transfer policies I assume. So if 2009:03 would be reverted, it would also allow transfers of larger blocks than what one might consume in 3 months. Which would be good looking at routing table size imho. Erik Bais From nick at inex.ie Mon Sep 3 18:06:30 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 03 Sep 2012 17:06:30 +0100 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <20120903135038.2D15F28422@prometheus.inex.ie> References: <20120903135038.2D15F28422@prometheus.inex.ie> Message-ID: <5044D586.8080304@inex.ie> On 03/09/2012 14:50, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > before 1 October 2012. This policy is sensible. Nick From lists-ripe at c4inet.net Mon Sep 3 18:19:18 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 3 Sep 2012 17:19:18 +0100 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <5044D586.8080304@inex.ie> References: <20120903135038.2D15F28422@prometheus.inex.ie> <5044D586.8080304@inex.ie> Message-ID: <20120903161918.GB69922@cilantro.c4inet.net> On Mon, Sep 03, 2012 at 05:06:30PM +0100, Nick Hilliard wrote: >This policy is sensible. +1 and, for the record, I support this change. rgds, Sascha Luck From jan at go6.si Mon Sep 3 18:37:49 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 03 Sep 2012 18:37:49 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <20120903143028.GQ13776@Space.Net> References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> <20120903143028.GQ13776@Space.Net> Message-ID: <5044DCDD.9090401@go6.si> On 9/3/12 4:30 PM, Gert Doering wrote: > We have all time of the world, as this only affects policy *after* the > IPv4 runout :-) (and there's no way to get this through before). > > This is not really aimed at "RIPE NCC address distribution", but as the > RIPE IPv4 address policy also sets the policy for "LIR to end customer > address assignment", and the *timelines* for that, it does make a > difference. Hi, apparently I misread and/or misuderstood the policy change proposal. From this point of view - it makes sense. > > To those LIRs that work operate to policy (which they all sign...), and > have some addresses left in stock... Yes. Cheers, Jan From boggits at gmail.com Mon Sep 3 17:52:42 2012 From: boggits at gmail.com (boggits) Date: Mon, 3 Sep 2012 16:52:42 +0100 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <002b01cd89eb$715220a0$53f661e0$@a2b-internet.com> References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> <002b01cd89eb$715220a0$53f661e0$@a2b-internet.com> Message-ID: On 3 September 2012 16:47, Erik Bais wrote: > This would also apply for the transfer policies I assume. So if 2009:03 > would be reverted, it would also allow transfers of larger blocks than what > one might consume in 3 months. > Which would be good looking at routing table size imho. but thats already covered by 2012-03 J -- James Blessing 07989 039 476 From gert at space.net Mon Sep 3 19:10:13 2012 From: gert at space.net (Gert Doering) Date: Mon, 3 Sep 2012 19:10:13 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> <002b01cd89eb$715220a0$53f661e0$@a2b-internet.com> Message-ID: <20120903171013.GS13776@Space.Net> Hi, On Mon, Sep 03, 2012 at 04:52:42PM +0100, boggits wrote: > On 3 September 2012 16:47, Erik Bais wrote: > > > This would also apply for the transfer policies I assume. So if 2009:03 > > would be reverted, it would also allow transfers of larger blocks than what > > one might consume in 3 months. > > Which would be good looking at routing table size imho. > > but thats already covered by 2012-03 True, there's overlap here - 2012-03 de-couples the timelines, while 2012-06 restores the old ones (for "everything that refers to them"). So we don't have a conflict here (but indeed, accepting 2012-06 and stalling 2012-03 would make 2012-03 somewhat superfluous). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tore.anderson at redpill-linpro.com Tue Sep 4 09:07:35 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 04 Sep 2012 09:07:35 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <20120903171013.GS13776@Space.Net> References: <20120903135034.24C5122B40D9@ipv6.go6.si> <5044B86C.7040803@go6.si> <002b01cd89eb$715220a0$53f661e0$@a2b-internet.com> <20120903171013.GS13776@Space.Net> Message-ID: <5045A8B7.9020701@redpill-linpro.com> * Gert Doering > (but indeed, accepting 2012-06 and stalling 2012-03 would make 2012-03 somewhat superfluous). Well, 2012-03 seeks to increase the need period for transfers of allocations to two years, while 2012-06 would only increase that period to one year. Therefore, if the WG wants the need period for transfers to increase to two years, 2012-03 is not superfluous at all (irrespective of the status of 2012-06). You could argue that by passing 2012-06 first, 2012-03 would be easier to pass, as it would then be a smaller change policy (+12 months rather than +21 months). On the other hand, you could also argue that 2012-06 undermines the rationale for 2012-03 - if the WG's opinion is that 12 months (but not 3 months) is a sufficiently long need period for transfers. It is my understanding that if both 2012-03 and 2012-06 passes (in that order), the change made by 2012-06 to section 5.0 would not actually change any actively used policy. There is still a small benefit to doing so anyway, in my opinion, as it would remove four paragraphs of defunct policy text. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From mueller at syr.edu Tue Sep 4 16:32:34 2012 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 4 Sep 2012 14:32:34 +0000 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <20120903103837.GA69922@cilantro.c4inet.net> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> It is odd that one would support the existence of a Whois database that tells anyone and everyone what organization is the registered holder of an address block, and at the same time be against documenting the movement (transfer) of a block from one holder to another. Do you believe the Whois data should all be private? As long as there is a Whois database, it will be possible to know where the address blocks go. The proposal simply makes it easier to track and analyze. So, unless he is willing to advocate eliminating Whois altogether, Sascha Luck's idea to "anonymize all transfer data" doesn't make a lot of sense to me. The reasons for making the address market easier to track are primarily policy-related, rather than "operational". The reasons for knowing the buyers and sellers in successful transfers are clearly explained in the initial proposal. We need to be able to assess how the market is working and its economic consequences. The market itself will work better and more efficiently with more transparency. You cannot buy and sell companies (legal persons) without the existence of the transaction and a large amount of other information about the companies being known. In most countries (not sure about all of Europe) buyers and sellers of real estate - houses, land - are completely public, as is the price and taxes paid for the property. And all the other RIRs with a transfer market make this information public. I think, therefore, the burden of proof is on those who would want to keep it hidden - actually not hidden, but just harder to access. What is the point of that? Why should RIPE region be an exception to the rest of the world? > -----Original Message----- > I'd go one further and anonymise all transfer data. Who has an > operational *need-to-know* this data? > > rgds, > Sascha Luck From lists-ripe at c4inet.net Tue Sep 4 19:13:56 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 4 Sep 2012 18:13:56 +0100 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20120904171356.GA84988@cilantro.c4inet.net> On Tue, Sep 04, 2012 at 02:32:34PM +0000, Milton L Mueller wrote: >movement (transfer) of a block from one holder to another. Do you >believe the Whois data should all be private? As long as there is a Yes, actually, or at least *more private*. IP space is not just allocated/assigned to corporations but also to private individuals. In my opinion, access to ripedb data is far too easy. Since I registered my first RIPE handle, there has not been a day when spam hasn't arrived to an email address clearly harvested from the ripedb. Yes indeed, I'd *love* to see much stricter access controls on this data. >Whois database, it will be possible to know where the address blocks >go. The proposal simply makes it easier to track and analyze. So, >unless he is willing to advocate eliminating Whois altogether, Sascha >Luck's idea to "anonymize all transfer data" doesn't make a lot of >sense to me. This is correct but you have to go actively looking for it rather than having it presented in a nice pre-digested package. >The reasons for making the address market easier to track are primarily >policy-related, rather than "operational". The reasons for knowing the >buyers and sellers in successful transfers are clearly explained in the >initial proposal. We need to be able to assess how the market is >working and its economic consequences. The market itself will work >better and more efficiently with more transparency. The RIRs have that data anyway and I've no major issue with that as long as it is not sold to every Tom, Dick & Harry without at least stripping out individually identifying information. Who might that "we" be who need to assess how the market is working? It seems to me that this sort of data (nicely aggregated lists of address space transfers and refusals) would mostly be useful to marketroids. Especially those who have various "get IP quick" scams on offer. >keep it hidden - actually not hidden, but just harder to access. What >is the point of that? Why should RIPE region be an exception to the >rest of the world? For one thing, personal data in the EU remains the property of the individual. This is not the case, eg. if it somehow gets to the US where it is the property of the holder and the individual to whom it refers has no rights over it whatsoever. rgds, Sascha Luck From mueller at syr.edu Tue Sep 4 19:29:19 2012 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 4 Sep 2012 17:29:19 +0000 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <20120904171356.GA84988@cilantro.c4inet.net> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > > Yes, actually, or at least *more private*. IP space is not just > allocated/assigned to corporations but also to private individuals. I am quite sympathetic to that, for natural (as opposed to legal) persons, but that whole issue is not relevant to this policy proposal. You are considering a policy change for the Whois, not for transfers transparency. Please don't confuse the two. > Who might that "we" be who need to assess how the market is working? > It seems to me that this sort of data (nicely aggregated lists of address > space transfers and refusals) would mostly be useful to marketroids. > Especially those who have various "get IP quick" scams on offer. On the contrary, brokerages would benefit from less transparency. Specialized brokerages, or what you somewhat insultingly refer to as "marketroids," will be easily able to analyze the Whois data to find out what transactions took place. It will pay them to know this and so you have widened the gap between what they know and what the rest of us know. It is the rest of us who will be left in the dark. The less we all know about the supply and demand conditions, the higher the margins and less efficient the market will be. So the "we" who need to assess the market are network operators who may be considering participating in that market, policy makers who want to know how well it is working, and policy researchers who want to answer the questions policy makers have. > For one thing, personal data in the EU remains the property of the > individual. This is not the case, eg. if it somehow gets to the US IP numbers will be traded in blocks. They do not function as PII (personally identifiable information) until and unless they are assigned to specific individuals as IP addresses. Therefore there are no issues related to data protection in a market transparency policy. And again, the information is there, we are just making it more accessible. Once again, you are confusing some of your concerns about privacy with Transparency in Address Block Transfers. The proposed policy 2012-05 neither improves the privacy situation nor makes it any worse than it is now. If you want to propose a Whois privacy policy to RIPE I would encourage you to do so, but by latching on to this policy, you are barking up the wrong tree. From lists-ripe at c4inet.net Tue Sep 4 20:59:07 2012 From: lists-ripe at c4inet.net (lists-ripe at c4inet.net) Date: Tue, 4 Sep 2012 19:59:07 +0100 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20120904185907.GB84988@cilantro.c4inet.net> On Tue, Sep 04, 2012 at 05:29:19PM +0000, Milton L Mueller wrote: >You are considering a policy change for the Whois, not for transfers >transparency. Please don't confuse the two. Please do not accuse me of something *you* brought into this discussion. I admit fault for falling into your trolling net though. Anyway, as long as all information like personal names, phone numbers, addresses and email are removed from these publications, I consider them suitably anonymised for the purposes of this policy. rgds, Sascha Luck From turchanyi.geza at gmail.com Wed Sep 5 08:16:20 2012 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 5 Sep 2012 08:16:20 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <20120904185907.GB84988@cilantro.c4inet.net> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> <20120904185907.GB84988@cilantro.c4inet.net> Message-ID: Sascha, On Tue, Sep 4, 2012 at 8:59 PM, wrote: > On Tue, Sep 04, 2012 at 05:29:19PM +0000, Milton L Mueller wrote: > >> You are considering a policy change for the Whois, not for transfers >> transparency. Please don't confuse the two. >> > > Please do not accuse me of something *you* brought into this > discussion. I admit fault for falling into your trolling net though. > > I am not sure I got what you mean. > Anyway, as long as all information like personal names, phone numbers, > addresses and email are removed from these publications, I consider them > suitably anonymised for the purposes of this policy. > > I share Milton's view that a name (etc) of a person acting in business is not personal only, however, a business ID, what is public information. This is the rule in my country which is not in the US and won't be. What you said: sometimes purely personal data also included in the whois database. Milton and I understood this argument, and Milton answer was: this is a "whois problem". I would say, this is problem of keeping the address allocation process transparent while allowing hiding individual only information, Milton's and my approach may be the same. > > rgds, > Sascha Luck > There is a trade-off: I vote for the trancparency of the address allocation (and any change in the address allocated). Thanks, G?za -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Wed Sep 5 08:32:11 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 05 Sep 2012 08:32:11 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <20120904171356.GA84988@cilantro.c4inet.net> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> Message-ID: <5046F1EB.10603@redpill-linpro.com> * Sascha Luck > Yes, actually, or at least *more private*. IP space is not just > allocated/assigned to corporations but also to private individuals. > In my opinion, access to ripedb data is far too easy. Since I registered > my first RIPE handle, there has not been a day when spam hasn't arrived > to an email address clearly harvested from the ripedb. > Yes indeed, I'd *love* to see much stricter access controls on this data. Assignments are out of scope. This proposal touches only on policy regarding allocations, which are exclusively delegated to LIRs. These must all be registered with the LIR's contact details - this proposal does not change this requirement in any way. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson at redpill-linpro.com Wed Sep 5 09:06:05 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 05 Sep 2012 09:06:05 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> Message-ID: <5046F9DD.9040004@redpill-linpro.com> * Sander Steffann > Looking at the feedback I see two types of responses: > - The policy proposal is good as it is > - Information on rejected transfer should be anonymised > > We could suggest to the proposer to add the 'anonymise rejected transfers' bit to the proposal, but we are not sure if that would gain support on one side while losing support from people who like the policy proposal as it currently is... > > So... Again your feedback please! Is there anyone who thinks that anonymising details of rejected transfers is a bad idea? (and if so: please explain why) I object to publishing information of rejected transfers (and, by extension, rejected pre-approvals). The NCC does not publish any information about rejected PA allocation requests either, and I don't see why transfers should be any different. If this requirement was removed, I would have no objections to the policy. That said, I am not quite sure it is really necessary, as all the requested information (except rejections) is already available: All allocations are listed in alloclist.txt along with their date and holding LIR (reg-id and name). It will be trivial to check for transfers - allocations made after the last /8 policy comes into effect outside of 185/8 must be transfers. (In addition, the allocation and date are also available in delegated-ripencc-extended-latest, and the details of the holding LIR is also available in the RIPE database.) The only information I know of that isn't easily accessible is which LIR originally held the transferred resource, since historic copies of alloclist.txt isn't available on the FTP. You would have had to build up your own archive by mirroring the file daily. I do expect that people who are interested in monitoring transfers would do just that, instead of waiting for the monthly digest called for by this proposal. I think that a simpler and probably much faster way (no PDP!) to accomplish the desired ?transparency in address block transfers? would be to simply ask the NCC to publish historic versions of alloclist.txt, and/or to include a regid/LIR column for resources in delegated-ripencc-extended-latest (for which historic archives are available). This has been recently suggested in the services wg, but it was objected to, because of privacy issues for assignment holders (so irrelevant relevant to this proposal). I think I'll go and revive that thread now... Oh, and by the way: why specify exactly monthly? As noted above, the NCC has no problems publishing most of this information on a daily basis. If they are able to automatically publish the transfer list daily too, why not let them? -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From jim at rfc1035.com Wed Sep 5 11:00:39 2012 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Sep 2012 10:00:39 +0100 Subject: [address-policy-wg] Personal Data and 2012-05 In-Reply-To: References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> <20120904185907.GB84988@cilantro.c4inet.net> Message-ID: On 5 Sep 2012, at 07:16, Turchanyi Geza wrote: > I share Milton's view that a name (etc) of a person acting in > business is > not personal only, however, a business ID, what is public > information. > This is the rule in my country which is not in the US and won't be. There are many views on what is and isn't Personal Data, even amongst European Data Protection Authorities who are working off the same EU Directives. Don't make the mistake of assuming everyone shares your view or that of your local DPA. Or that those views might or might not change tomorrow. Strictly speaking any data which identifies a living person constitutes Personal Data. Therefore that data falls within scope of the EU Directives and the prevailing national laws which enacted them. However some, but by no means all, European DPAs take a pragmatic view and consider end user expectations and/or the intent behind publishing Personal Data when deciding what is and isn't acceptable. Other DPAs may take a much more literal approach to what's in the Directive and local law. So what's "legal" in one jurisdiction may well be "illegal" in another even though both positions are based on the same EU Directives. This situation might well apply in non-EU countries which have Data Protection legislation too. Things can get even murkier if you go into greater detail. For instance my former ISP added contact details for me to the RIPE database when they gave me a /29. This was OK from the DPA's perspective since the intent was reasonable: maintaining an accurate, public database of who was using address space. However it was also not OK because the entries were added without my consent and I had no clear way to update them. Those entries were still in the database several months after the space had been handed back. That wasn't OK either. Schrodinger's cat has/had a very happy home in Data Protection. :-) Anyway, this latest rat-holing is somewhat irrelevant. If contact information for IP address resources need to be obscured for whatever reason -- commercial confidentiality, data protection/privacy, preventing spam, etc -- methods for that already exist and could be applied. In some cases, they already are in use. Others may well be invented. Just look at the "imaginitive" solutions found in the domain name world for obfuscating whois data. If we look in the real world, the public registers of physical assets such as shares and property regularly contain entries for things like lawyers's offices, nominee accounts, offshore companies/trusts and so on so that the details of the real owner remain hidden. From Woeber at CC.UniVie.ac.at Wed Sep 5 11:50:15 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Sep 2012 11:50:15 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <20120903103837.GA69922@cilantro.c4inet.net> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> Message-ID: <50472057.1060502@CC.UniVie.ac.at> [with my DB-WG hat on for a moment...] Sascha Luck wrote: > On Mon, Sep 03, 2012 at 12:28:59PM +0200, Sander Steffann wrote: > >> So... Again your feedback please! Is there anyone who thinks that >> anonymising details of rejected transfers is a bad idea? (and if so: >> please explain why) > > > I'd go one further and anonymise all transfer data. Is this an issue at all, to begin with, as the rightful holder of the allocation will at any time be recorded in the Numbers Registry, aka the RIPE DB? I may be missing something, though! > Who has an > operational *need-to-know* this data? > > rgds, > Sascha Luck > Wilfried. From Woeber at CC.UniVie.ac.at Wed Sep 5 12:04:02 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Sep 2012 12:04:02 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> Message-ID: <50472392.303@CC.UniVie.ac.at> [this comment is made with my view as a LIR manager] Milton L Mueller wrote: >>-----Original Message----- >> >>Besides publishing a list of v4 resources that have been moved, > > > That is the sum and substance of what 2012-05 is intended to do. > It does what ARIN and APNIC already do: provide an accessible list of resources that have been moved according to the transfer policies in place. > > >>what does this accomplish that sub-allocations don't already do? >>Is the recipient LIR charged according to the resources under their >>registry file? > > > Like the previous question that was raised, you seem to be asking questions > about the transfer policy itself, not about this proposal. The transfer policy > already exists and it is what it is. Each and every existing policy is subject to review, change and/or improvement. Thus, when there is a proposal to amend existing policy text, this might be a good point in time to have a look at the whole set of provisions. With that point of view I'd like to ask for clarification of the following provision: " 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. " But the receiving LIR may do so with other parts from their IPv4 address pool? What is the motivation for that particular restriction and for that particular wording? And, I am wondering, whether the following restriction is (still) useful: " The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. " in particular at a point in time when Registration Services has distributed the following announcement (Sept. 4, 2012 [1] ): - Depending on the availability in the RIPE NCC?s free pool of IPv4 address space, you may receive multiple smaller prefixes that add up to the size of your request. > All this proposal does it let the community know who is using it, and to better > assess and track its consequences. > > --MM Wwilfried [1] Subject: RIPE NCC has Approximately Four Million IPv4 Addresses Before Reaching Last /8 From tore.anderson at redpill-linpro.com Wed Sep 5 12:16:00 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 05 Sep 2012 12:16:00 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <50472392.303@CC.UniVie.ac.at> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> Message-ID: <50472660.5050709@redpill-linpro.com> * Wilfried Woeber, UniVie/ACOnet > Each and every existing policy is subject to review, change and/or improvement. > Thus, when there is a proposal to amend existing policy text, this might be a > good point in time to have a look at the whole set of provisions. I disagree. > " > 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. > " > " > The block that is to be re-allocated must not be smaller than the minimum > allocation block size at the time of re-allocation. > " Your questions are off topic, as both of those sentences you quoated are not modified in any way by 2012-05. You are of course free to start a new discussion about them, submit a new proposal to change them, and so forth. But please, don't hijack the 2012-05 thread. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Woeber at CC.UniVie.ac.at Wed Sep 5 12:29:21 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Sep 2012 12:29:21 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <5046F9DD.9040004@redpill-linpro.com> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> Message-ID: <50472981.4090709@CC.UniVie.ac.at> Tore Anderson wrote: > * Sander Steffann > > >>Looking at the feedback I see two types of responses: >>- The policy proposal is good as it is >>- Information on rejected transfer should be anonymised >> >>We could suggest to the proposer to add the 'anonymise rejected transfers' bit to the proposal, but we are not sure if that would gain support on one side while losing support from people who like the policy proposal as it currently is... >> >>So... Again your feedback please! Is there anyone who thinks that anonymising details of rejected transfers is a bad idea? (and if so: please explain why) > > > I object to publishing information of rejected transfers (and, by > extension, rejected pre-approvals). I concur, strongly. It would be useful, though to have some sort of aggregate data about failures, like e.g. #of failed vs successful transactions, granularity of requests, and the like. I haven't thought to the end of this stick, yet :-) > The NCC does not publish any > information about rejected PA allocation requests either, and I don't > see why transfers should be any different. I agree. [...] > I think that a simpler and probably much faster way (no PDP!) to > accomplish the desired ?transparency in address block transfers? would > be to simply ask the NCC to publish historic versions of alloclist.txt, Well, I don't like the idea of publicly and easily offering such a history. [This is with my security team hat on :-) Although, with the same hat on, I would love to have such a thing...] As the NCC has to shorten the quarantine period for returned or reclaimed addresses, offering this may be painful for the new/current holders of the resource. On top of that, from a formal perspective, if there is no longer a (contractual) relationship with the NCC, I do not see a sound basis for the NCC to make old data publicly accessible. > and/or to include a regid/LIR column for resources in > delegated-ripencc-extended-latest (for which historic archives are > available). This has been recently suggested in the services wg, but it > was objected to, because of privacy issues for assignment holders (so > irrelevant relevant to this proposal). I think I'll go and revive that > thread now... > > Oh, and by the way: why specify exactly monthly? As noted above, the NCC > has no problems publishing most of this information on a daily basis. If > they are able to automatically publish the transfer list daily too, why > not let them? I'd rather like the NCC to come forward with a proposal of how to make the requested data available, and describe its format(!) than prescribing details in a formal policy. The mechanism may even be a webpage or feed that gets updated when the DB gets updated to reflect the transfer :-) Wilfried. From erik at bais.name Wed Sep 5 12:31:51 2012 From: erik at bais.name (Erik Bais) Date: Wed, 5 Sep 2012 12:31:51 +0200 Subject: [address-policy-wg] Status request : 2012-04 - PI Assignments from the last /8 Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5867@EXVS002.netsourcing.lan> Hi, Could someone provide insight in the policy 2012-04? With the final /8 within grasp, I would like to have it clear where we stand. Current Phase Ends: 19 July 2012 Current Phase: Discussion Phase: Awaiting Decision from Proposer Awaiting Documentation Regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From turchanyi.geza at gmail.com Wed Sep 5 13:59:11 2012 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 5 Sep 2012 13:59:11 +0200 Subject: [address-policy-wg] Personal Data and 2012-05 In-Reply-To: References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <20120903103837.GA69922@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220C7D1@SUEX10-mbx-10.ad.syr.edu> <20120904171356.GA84988@cilantro.c4inet.net> <855077AC3D7A7147A7570370CA01ECD220CE13@SUEX10-mbx-10.ad.syr.edu> <20120904185907.GB84988@cilantro.c4inet.net> Message-ID: Jim, thanks for your clarifications, I better understand your concerns. However, business related ID should be accessible publicly. If I know well, all public procurement require the correct ownership data, etc in Europe, and not just hidden, disguised ones. Best, G?za On Wed, Sep 5, 2012 at 11:00 AM, Jim Reid wrote: > On 5 Sep 2012, at 07:16, Turchanyi Geza wrote: > > I share Milton's view that a name (etc) of a person acting in business is >> not personal only, however, a business ID, what is public information. >> This is the rule in my country which is not in the US and won't be. >> > > There are many views on what is and isn't Personal Data, even amongst > European Data Protection Authorities who are working off the same EU > Directives. Don't make the mistake of assuming everyone shares your view or > that of your local DPA. Or that those views might or might not change > tomorrow. > > Strictly speaking any data which identifies a living person constitutes > Personal Data. Therefore that data falls within scope of the EU Directives > and the prevailing national laws which enacted them. However some, but by > no means all, European DPAs take a pragmatic view and consider end user > expectations and/or the intent behind publishing Personal Data when > deciding what is and isn't acceptable. Other DPAs may take a much more > literal approach to what's in the Directive and local law. So what's > "legal" in one jurisdiction may well be "illegal" in another even though > both positions are based on the same EU Directives. This situation might > well apply in non-EU countries which have Data Protection legislation too. > > Things can get even murkier if you go into greater detail. For instance my > former ISP added contact details for me to the RIPE database when they gave > me a /29. This was OK from the DPA's perspective since the intent was > reasonable: maintaining an accurate, public database of who was using > address space. However it was also not OK because the entries were added > without my consent and I had no clear way to update them. Those entries > were still in the database several months after the space had been handed > back. That wasn't OK either. > > Schrodinger's cat has/had a very happy home in Data Protection. :-) > > Anyway, this latest rat-holing is somewhat irrelevant. If contact > information for IP address resources need to be obscured for whatever > reason -- commercial confidentiality, data protection/privacy, preventing > spam, etc -- methods for that already exist and could be applied. In some > cases, they already are in use. Others may well be invented. Just look at > the "imaginitive" solutions found in the domain name world for obfuscating > whois data. If we look in the real world, the public registers of physical > assets such as shares and property regularly contain entries for things > like lawyers's offices, nominee accounts, offshore companies/trusts and so > on so that the details of the real owner remain hidden. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emadaio at ripe.net Wed Sep 5 14:33:16 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 05 Sep 2012 14:33:16 +0200 Subject: [address-policy-wg] Status request : 2012-04 - PI Assignments from the last /8 In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5867@EXVS002.netsourcing.lan> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5867@EXVS002.netsourcing.lan> Message-ID: <5047468C.9030808@ripe.net> Dear Erik, Thank you for you question. The RIPE NCC has identified a number of additional points to review. We are about to complete our Impact Analysis on the proposal 2012-04 and the Review Phase will begin no later than the beginning of next week. For further details you can check my previous announcement: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-August/007038.html Apologies for any inconvenience. Regards Emilio Madaio Policy Development Officer RIPE NCC On 9/5/12 12:31 PM, Erik Bais wrote: > Hi, > > > > Could someone provide insight in the policy 2012-04? > > > > With the final /8 within grasp, I would like to have it clear where we > stand. > > > > Current Phase Ends: > > 19 July 2012 > > > > Current Phase: > > Discussion Phase: Awaiting Decision from Proposer > > Awaiting Documentation > > > > Regards, > > Erik Bais > From emadaio at ripe.net Wed Sep 5 14:52:18 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 05 Sep 2012 14:52:18 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Review Period on Version 2 of Draft Document, for Reverse Address Delegation of IPv4 and IPv6 Address Space Message-ID: <50474B02.1050204@ripe.net> Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-302, "Policy for Reverse Address Delegation of IPv4 and IPv6 address space in the RIPE NCC Service Region". After the feedback in the previous review phase, a new draft (2.0) of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-documents The highlights of the changes from the previous version include: -the removal of all unnecessary references to "reverse resolution" -the rewording and simplification of section 4.0 In response to the community's request: -section 3.0 focuses on who is able to ask for the delegation -the reference to the obsolete RFC 2874 has been replaced with the relevant active RFCs The Address Policy Working Group Co-Chairs decided to extend the review period until 3 October 2012 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at: . Kind regards, Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Wed Sep 5 15:19:41 2012 From: gert at space.net (Gert Doering) Date: Wed, 5 Sep 2012 15:19:41 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <50472392.303@CC.UniVie.ac.at> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> Message-ID: <20120905131941.GK13776@Space.Net> Hi, On Wed, Sep 05, 2012 at 12:04:02PM +0200, Wilfried Woeber, UniVie/ACOnet wrote: > With that point of view I'd like to ask for clarification of the following > provision: > > " > 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. > " > > But the receiving LIR may do so with other parts from their IPv4 address pool? > What is the motivation for that particular restriction and for that particular > wording? Getting a transfer policy in place "back in the days" was a very difficult process, and the net result is a compromise... that particular sentence was there because it was feared that people would stockpile address space, wait for the price to rise, and then sell it off at a higher price - so, you have to sit on it for 24 months. This is not talking about a normal LIR, which has some free space here and there, might need something extra for a while, and then sell it off again... > And, I am wondering, whether the following restriction is (still) useful: > > " > The block that is to be re-allocated must not be smaller than the minimum > allocation block size at the time of re-allocation. > " Well, it's an attempt to avoid even further fragmentation of the IPv4 address space (and subsequent burdening of the routing system). We haven't seen that many transfers yet, so I, at least, don't know how "useful" or "harmful" that restriction is in practice. Shall we put these two topics on the agenda for the upcoming RIPE meeting (in "Y. Open Policy Hour")? Would you be willing to lead the discussion? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mueller at syr.edu Wed Sep 5 15:21:43 2012 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 5 Sep 2012 13:21:43 +0000 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <50472660.5050709@redpill-linpro.com> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> Agree with Tore Anderson here. Much as I would love to discuss modification of other aspects of the transfer policy, and as important as the questions raised by Wilfried are, they are not germane to 2012-5 at all. > -----Original Message----- > From: Tore Anderson [mailto:tore.anderson at redpill-linpro.com] > > Thus, when there is a proposal to amend existing policy text, this > > might be a good point in time to have a look at the whole set of > provisions. > > I disagree. > > > " > > 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. > > " > > > " > > The block that is to be re-allocated must not be smaller than the > > minimum allocation block size at the time of re-allocation. > > " > > Your questions are off topic, as both of those sentences you quoated are > not modified in any way by 2012-05. > > You are of course free to start a new discussion about them, submit a > new proposal to change them, and so forth. But please, don't hijack the > 2012-05 thread. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com From Woeber at CC.UniVie.ac.at Wed Sep 5 15:32:30 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Sep 2012 15:32:30 +0200 Subject: [address-policy-wg] Status request : 2012-04 - PI Assignments from the last /8 In-Reply-To: <5047468C.9030808@ripe.net> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5867@EXVS002.netsourcing.lan> <5047468C.9030808@ripe.net> Message-ID: <5047546E.6030204@CC.UniVie.ac.at> Hi Emilio, looking at 2012-04 and 2012-05(ripe-553bis) to potentially exist in parallel, would addresses distributed under the final /8 regime be subject to "transfer"? Wilfried From mueller at syr.edu Wed Sep 5 15:40:15 2012 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 5 Sep 2012 13:40:15 +0000 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <5046F9DD.9040004@redpill-linpro.com> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Tore Anderson > Sent: Wednesday, September 05, 2012 3:06 AM > > So... Again your feedback please! Is there anyone who thinks that > > anonymising details of rejected transfers is a bad idea? (and if so: > > please explain why) > > I object to publishing information of rejected transfers (and, by > extension, rejected pre-approvals). The NCC does not publish any > information about rejected PA allocation requests either, and I don't > see why transfers should be any different. [Milton L Mueller] You have not given us any reason not to provide this information, other than "we haven't done it before" - which I do not accept as a good reason. I will tell you why we need to do this. There are serious concerns in the existing transfer market about potential discrimination in the application of needs assessments, at least in the ARIN region. Needs assessment is not an entirely scientific or objective exercise. Providing basic statistical information about how many applications are rejected avoids undermining confidentiality but also provides some knowledge as to how many attempted transfers are coming in and how many are rejected. If there are complaints about the application of needs assessment criteria - and there already are in other regions - at least the community has some information about > That said, I am not quite sure it is really necessary, as all > the requested information (except rejections) is already available: All > allocations are listed in alloclist.txt along with their date and > holding LIR (reg-id and name). It will be trivial to check for transfers > - allocations made after the last /8 policy comes into effect outside of [Milton L Mueller] Trivial to whom? To someone who has a system set up to constantly track this or who has bulk access to the entire database and can write scripts to check for it on a regular basis? This is not reasonable. RIRs need to recognize the significance of the emergence of a transfer market. The attitudes here in RIPE that I detect are incredibly complacent. A market for addresses will profoundly transform the nature of IP number allocation. All RIRs are obligated to do everything they can to make this market easily understood, transparent and efficient. Why shouldn't they? Can you provide a positive reason why not? > The only information I know of that isn't easily accessible is which LIR > originally held the transferred resource, since historic copies of > alloclist.txt isn't available on the FTP. You would have had to build up > your own archive by mirroring the file daily. I do expect that people > who are interested in monitoring transfers would do just that, instead > of waiting for the monthly digest called for by this proposal. [Milton L Mueller] I think the description you provide of what would be necessary to track this information without the policy proposed in 2012-5 self-evidently proves that this policy is needed. Your approach is complex, expensive and would limit this information to a few specialists who would keep the data proprietary in order to protect their investment in collecting it. My proposal would make it accessible to anyone. You have not provided any good reason to limit it in that way. You have not provided any costs or harms that would occur if the information is made accessible. Perhaps you can do so? > I think that a simpler and probably much faster way (no PDP!) to > accomplish the desired would > be to simply ask the NCC to publish historic versions of alloclist.txt, > and/or to include a regid/LIR column for resources in delegated-ripencc- > extended-latest (for which historic archives are available). This has > been recently suggested in the services wg, but it was objected to, > because of privacy issues for assignment holders (so irrelevant relevant > to this proposal). I think I'll go and revive that thread now... [Milton L Mueller] No, that is not "simpler". Not by any reasonable definition of "simple." RIPE could easily make this accessible to all with a few keystrokes and procedural change at the source. Can you explain why it should not? > Oh, and by the way: why specify exactly monthly? As noted above, the NCC > has no problems publishing most of this information on a daily basis. If > they are able to automatically publish the transfer list daily too, why > not let them? [Milton L Mueller] This is a valid modification. I would be happy with "daily" From tore.anderson at redpill-linpro.com Wed Sep 5 16:35:00 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 05 Sep 2012 16:35:00 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> Message-ID: <50476314.10307@redpill-linpro.com> * Milton L Mueller >> I object to publishing information of rejected transfers (and, by >> extension, rejected pre-approvals). The NCC does not publish any >> information about rejected PA allocation requests either, and I >> don't see why transfers should be any different. > > [Milton L Mueller] You have not given us any reason not to provide > this information, other than "we haven't done it before" - which I do > not accept as a good reason. I, like the NCC, consider this data to be confidential. Let's say I want to transfer an allocation to another LIR, and want the fact that I've been dealing with said LIR to remain a secret until the deal is done. If the deal falls through due to the failure of the recipient LIR to justify their need for the transferred resource, I don't want the fact I was in negotiations to transfer away 192.0.2.0/24 to become public knowledge. > I will tell you why we need to do this. There are serious concerns in > the existing transfer market about potential discrimination in the > application of needs assessments, at least in the ARIN region. Needs > assessment is not an entirely scientific or objective exercise. > Providing basic statistical information about how many applications > are rejected avoids undermining confidentiality but also provides > some knowledge as to how many attempted transfers are coming in and > how many are rejected. If there are complaints about the application > of needs assessment criteria - and there already are in other regions > - at least the community has some information about This is a red herring. The proposal does not call for ?basic statistical information about how many applications are rejected?, it calls for the explicit identification of origin LIR and the address block it intended to transfer away. Also, if the goal of the identification is to combat discrimination in need assessment, isn't it the *receiving* LIR that should be identified? How is the identity of the LIR giving up its allocation, and the identity of the allocation itself, relevant to need assessment? I have no objection to having the NCC publish aggregate information about how many transfer tickets they've handled and how many of them was approved. That said, I'm not so sure we would need to have a policy for it, it might be simpler to just ask them to publish the information in aggregate form. For example, they do something along those lines at http://www.ripe.net/lir-services/resource-management/tools-for-lirs/reponse-time-ipv4 without there being any policy compelling them to. >> That said, I am not quite sure it is really necessary, as all the >> requested information (except rejections) is already available: >> All allocations are listed in alloclist.txt along with their date >> and holding LIR (reg-id and name). It will be trivial to check for >> transfers - allocations made after the last /8 policy comes into >> effect outside of > > [Milton L Mueller] Trivial to whom? To someone who has a system set > up to constantly track this or who has bulk access to the entire > database and can write scripts to check for it on a regular basis? Yes. It's not difficult. You basically download two files and see what has changed. > This is not reasonable. RIRs need to recognize the significance of > the emergence of a transfer market. The attitudes here in RIPE that I > detect are incredibly complacent. A market for addresses will > profoundly transform the nature of IP number allocation. All RIRs are > obligated to do everything they can to make this market easily > understood, transparent and efficient. Why shouldn't they? Can you > provide a positive reason why not? I think both the RIPE community and the NCC fully realise that transfers will play a significant role in the near future. > [Milton L Mueller] I think the description you provide of what would > be necessary to track this information without the policy proposed in > 2012-5 self-evidently proves that this policy is needed. Your > approach is complex, expensive and would limit this information to a > few specialists who would keep the data proprietary in order to > protect their investment in collecting it. I think you are greatly over-estimating how difficult it is to parse and extract information from the stats files available on the FTP. I think anyone with basic programming or scripting skills would have no problems. I'll be happy to provide you or anyone else with a script that generates the report you want based off the stats files, if the NCC makes all the necessary information available there. > My proposal would make it > accessible to anyone. You have not provided any good reason to limit > it in that way. You have not provided any costs or harms that would > occur if the information is made accessible. Perhaps you can do so? Like I said, I have no objection to the proposal other than the part regarding publishing identifying details about rejected transfers. That said, I think there is likely much faster ways to accomplish the desired transparency than going through the PDP. I think going through the PDP is over-engineering. Don't mistake that for opposition to the proposal though. >> I think that a simpler and probably much faster way (no PDP!) to >> accomplish the desired >> would be to simply ask the NCC to publish historic versions of >> alloclist.txt, and/or to include a regid/LIR column for resources >> in delegated-ripencc- extended-latest (for which historic archives >> are available). This has been recently suggested in the services >> wg, but it was objected to, because of privacy issues for >> assignment holders (so irrelevant relevant to this proposal). I >> think I'll go and revive that thread now... > > [Milton L Mueller] No, that is not "simpler". Not by any reasonable > definition of "simple." RIPE could easily make this accessible to all > with a few keystrokes and procedural change at the source. Can you > explain why it should not? >From the 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?. So yes indeed, ?RIPE[sic] could easily make this accessible to all with a few keystrokes?. They have stated a willingness to do so, too. So why do we need to change policy, exactly? The PDP is a slow process. It seems to me that it is faster to just ask the NCC to start publishing the desired information. If they refuse to do so, then let's look into compelling them through policy. IMHO, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From maildanrl at gmail.com Thu Sep 6 14:23:51 2012 From: maildanrl at gmail.com (Dan Luedtke) Date: Thu, 6 Sep 2012 14:23:51 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> Message-ID: I don't see how anyone can be against this proposal. The whole address assignment process should be as open as possible as long as the privacy of individuals is not concerned. From what I understand, this proposal is good for the community, for the price of a rare but somehow "public" good and for the routing system in general. I support the proposal. Regards Dan From gert at space.net Thu Sep 6 14:50:00 2012 From: gert at space.net (Gert Doering) Date: Thu, 6 Sep 2012 14:50:00 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20120906125000.GD13776@Space.Net> Hi, On Thu, Sep 06, 2012 at 02:23:51PM +0200, Dan Luedtke wrote: > I don't see how anyone can be against this proposal. > The whole address assignment process should be as open as possible as > long as the privacy of individuals is not concerned. From what I > understand, this proposal is good for the community, for the price of > a rare but somehow "public" good and for the routing system in > general. > I support the proposal. "as is", or "with anonymizing rejected applications"? 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 mueller at syr.edu Thu Sep 6 14:53:57 2012 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 6 Sep 2012 12:53:57 +0000 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <50476314.10307@redpill-linpro.com> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> <50476314.10307@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > Let's say I want to transfer an allocation to another LIR, and want the > fact that I've been dealing with said LIR to remain a secret until the > deal is done. If the deal falls through due to the failure of the > recipient LIR to justify their need for the transferred resource, I > don't want the fact I was in negotiations to transfer away 192.0.2.0/24 > to become public knowledge. OK, this is a valid concern, imho. I would propose to modify the language such that statistical aggregates are published rather than individual blocks. > Also, if the goal of the identification is to combat discrimination in > need assessment, isn't it the *receiving* LIR that should be identified? Correct. Would you object if they were? Would others? > I have no objection to having the NCC publish aggregate information > about how many transfer tickets they've handled and how many of them > was approved. That said, I'm not so sure we would need to have a policy for > it, it might be simpler to just ask them to publish the information in > aggregate form. For example, they do something along those lines at > http://www.ripe.net/lir-services/resource-management/tools-for- > lirs/reponse-time-ipv4 > without there being any policy compelling them to. Whatever is easier. > So yes indeed, a few keystrokes>. They have stated a willingness to do so, too. So why > do we need to change policy, exactly? The PDP is a slow process. It > seems to me that it is faster to just ask the NCC to start publishing > the desired information. If they refuse to do so, then let's look into > compelling them through policy. Valid points! But on the other hand if we ask them to do it and they don't, then the process becomes even slower, doesn't it? I would prefer to go ahead with the policy change, but as you suggest remove the stuff about failed needs assessments, turn that into a request from RIPE for aggregate statistics. Are we in agreement on that? If so, I will propose a specific modification of the proposal From frettled at gmail.com Thu Sep 6 14:54:59 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 6 Sep 2012 14:54:59 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> Message-ID: On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke wrote: > I don't see how anyone can be against this proposal. > I don't see the real world benefit of the proposal, there are insufficient arguments for it, and I'm therefore with Tore on this one. (So now you perhaps see how anyone _can_ be against it.) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Sep 6 15:08:07 2012 From: gert at space.net (Gert Doering) Date: Thu, 6 Sep 2012 15:08:07 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> Message-ID: <20120906130807.GE13776@Space.Net> Hi, On Thu, Sep 06, 2012 at 02:54:59PM +0200, Jan Ingvoldstad wrote: > On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke wrote: > > > I don't see how anyone can be against this proposal. > > I don't see the real world benefit of the proposal, there are insufficient > arguments for it, and I'm therefore with Tore on this one. > > (So now you perhaps see how anyone _can_ be against it.) Uh. Can you please be a bit more explicit, as not everybody might remember Tore's stance on this? I take it that you are opposing the proposal? Any variant of the proposal, or would you support the "publish, but anonymize rejected transfers" option? It's a bit hard for the chairs to figure out which way to go if opinions are not stated clearly... thanks, 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 frettled at gmail.com Thu Sep 6 15:59:43 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 6 Sep 2012 15:59:43 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <20120906130807.GE13776@Space.Net> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> <20120906130807.GE13776@Space.Net> Message-ID: On Thu, Sep 6, 2012 at 3:08 PM, Gert Doering wrote: > Hi, > > On Thu, Sep 06, 2012 at 02:54:59PM +0200, Jan Ingvoldstad wrote: > > On Thu, Sep 6, 2012 at 2:23 PM, Dan Luedtke wrote: > > > > > I don't see how anyone can be against this > proposal. > > > > I don't see the real world benefit of the proposal, there are > insufficient > > arguments for it, and I'm therefore with Tore on this one. > > > > (So now you perhaps see how anyone _can_ be against it.) > > Uh. Can you please be a bit more explicit, as not everybody might remember > Tore's stance on this? > Oh, I'm terribly sorry, that was extremely clumsy of me! Tore's stance is here: http://lists.ripe.net/pipermail/address-policy-wg/2012-September/007063.html > I take it that you are opposing the proposal? Any variant of the proposal, > or would you support the "publish, but anonymize rejected transfers" > option? > The stance that I'm agreeing with is regarding publication of rejected transfers and rejected pre-approvals, so "publish, but anonymize rejected transfers/pre-approvals" is good with me. And, for the record, I agree with the notion that the NCC may: - publish aggregates - historical versions of alloclist.txt without any change in policy. > It's a bit hard for the chairs to figure out which way to go if opinions > are not stated clearly... > Yes, absolutely, and I apologize for being fuzzy. This is one of the times where a "me, too" is insufficient. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Sep 6 17:28:13 2012 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 6 Sep 2012 15:28:13 +0000 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> <20120906130807.GE13776@Space.Net> Message-ID: <855077AC3D7A7147A7570370CA01ECD220EBE1@SUEX10-mbx-10.ad.syr.edu> The stance that I'm agreeing with is regarding publication of rejected transfers and rejected pre-approvals, so "publish, but anonymize rejected transfers/pre-approvals" is good with me. OK, then, you are not disagreeing with the policy proposal, only with one aspect of it which I have agreed to change. I take it you also agree with Tore that the aggregate data can be published by RIPE-NN via request rather than through policy change? Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Thu Sep 6 17:31:55 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 6 Sep 2012 17:31:55 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220EBE1@SUEX10-mbx-10.ad.syr.edu> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> <20120906130807.GE13776@Space.Net> <855077AC3D7A7147A7570370CA01ECD220EBE1@SUEX10-mbx-10.ad.syr.edu> Message-ID: On Thu, Sep 6, 2012 at 5:28 PM, Milton L Mueller wrote: > OK, then, you are not disagreeing with the policy proposal, only with > one aspect of it which I have agreed to change. > I'm sorry, I missed that. > I take it you also agree with Tore that the aggregate data can be > published by RIPE-NN via request rather than through policy change? > Yes, I think that is the most sensible approach. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Sep 6 19:18:27 2012 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 Sep 2012 18:18:27 +0100 Subject: [address-policy-wg] Cosmetic Surgery Project: Review Period on Version 2 of Draft Document, for Reverse Address Delegation of IPv4 and IPv6 Address Space In-Reply-To: <50474B02.1050204@ripe.net> References: <50474B02.1050204@ripe.net> Message-ID: <5048DAE3.6040908@inex.ie> On 05/09/2012 13:52, Emilio Madaio wrote: > The Address Policy Working Group Co-Chairs decided to extend the review > period until 3 October 2012 to allow the community more time to give > their feedback. looks fine to me. Nick From Woeber at CC.UniVie.ac.at Thu Sep 6 22:20:55 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 06 Sep 2012 22:20:55 +0200 Subject: [address-policy-wg] Cosmetic Surgery Project: Review Period on Version 2 of Draft Document, for Reverse Address Delegation of IPv4 and IPv6 Address Space In-Reply-To: <5048DAE3.6040908@inex.ie> References: <50474B02.1050204@ripe.net> <5048DAE3.6040908@inex.ie> Message-ID: <504905A7.90305@CC.UniVie.ac.at> Nick Hilliard wrote: > On 05/09/2012 13:52, Emilio Madaio wrote: > >>The Address Policy Working Group Co-Chairs decided to extend the review >>period until 3 October 2012 to allow the community more time to give >>their feedback. > > > looks fine to me. > > Nick Same here. Wilfried From tore.anderson at redpill-linpro.com Fri Sep 7 09:08:05 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 07 Sep 2012 09:08:05 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> <50476314.10307@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> Message-ID: <50499D55.5050203@redpill-linpro.com> * Milton L Mueller >> -----Original Message----- Let's say I want to transfer an >> allocation to another LIR, and want the fact that I've been dealing >> with said LIR to remain a secret until the deal is done. If the >> deal falls through due to the failure of the recipient LIR to >> justify their need for the transferred resource, I don't want the >> fact I was in negotiations to transfer away 192.0.2.0/24 to become >> public knowledge. > > OK, this is a valid concern, imho. I would propose to modify the > language such that statistical aggregates are published rather than > individual blocks. Thanks - that would resolve my objection to the proposal. >> Also, if the goal of the identification is to combat discrimination >> in need assessment, isn't it the *receiving* LIR that should be >> identified? > > Correct. Would you object if they were? Would others? I would. I feel that neither the source nor the recipient of a failed transfer should be named. This extends to the address block itself (from which it would have been trivial to figure out the source.) In summary, my position is that: * Source/dest/prefix for successful transfers should definitively be made public. * Aggregate statistical data both for failed and successful transfers is ?nice to have?. * Information that identifies the specific parties or resources associated with a failed transaction should *not* be made public. >> So yes indeed, > with a few keystrokes>. They have stated a willingness to do so, >> too. So why do we need to change policy, exactly? The PDP is a slow >> process. It seems to me that it is faster to just ask the NCC to >> start publishing the desired information. If they refuse to do so, >> then let's look into compelling them through policy. > > Valid points! But on the other hand if we ask them to do it and they > don't, then the process becomes even slower, doesn't it? I would > prefer to go ahead with the policy change, but as you suggest remove > the stuff about failed needs assessments, turn that into a request > from RIPE for aggregate statistics. > > Are we in agreement on that? If so, I will propose a specific > modification of the proposal Agreed. I would not object to such a proposal. That said, I won't guarantee that I will come out and explicitly support it either (at least not until I've seen you simply ask the NCC to publish the desired data and been refused), but I promise I won't stand in your way. (I think services-wg would be the right place to ask the NCC for the data, by the way.) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From Niall.oReilly at ucd.ie Fri Sep 7 10:13:15 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 7 Sep 2012 09:13:15 +0100 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <50499D55.5050203@redpill-linpro.com> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> <50476314.10307@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> <50499D55.5050203@redpill-linpro.com> Message-ID: <72C79BB3-D6D9-4A89-9792-EB644142AEDA@ucd.ie> On 7 Sep 2012, at 08:08, Tore Anderson wrote: > * Aggregate statistical data both for failed and successful transfers is > ?nice to have?. Should the statistics for failure distinguish between the cases "withdrawn" (as when the deal falls through) and "refused" (as when the NCC's resource analysis process determines that the requirements are not met)? /Niall From tore.anderson at redpill-linpro.com Fri Sep 7 10:38:44 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 07 Sep 2012 10:38:44 +0200 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <72C79BB3-D6D9-4A89-9792-EB644142AEDA@ucd.ie> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> <50476314.10307@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> <50499D55.5050203@redpill-linpro.com> <72C79BB3-D6D9-4A89-9792-EB644142AEDA@ucd.ie> Message-ID: <5049B294.1000604@redpill-linpro.com> * Niall O'Reilly > > On 7 Sep 2012, at 08:08, Tore Anderson wrote: > >> * Aggregate statistical data both for failed and successful transfers is >> ?nice to have?. > > Should the statistics for failure distinguish between the > cases "withdrawn" (as when the deal falls through) > and "refused" (as when the NCC's resource analysis process > determines that the requirements are not met)? I'm guessing the updated proposal Milton just announced will contain a specification on exactly which data should be included in the stats. (Personally, I love stats and colourful graphs of all kinds so I'll be happy to see the distinction being made.) I remain unconvinced that we need to change address policy in order to get these stats made available, though. It seems more like an NCC service to me - that it would be better to simply ask the NCC ?could you please put up a graph on www.ripe.net containing plots X, Y, and Z? and/or ?could you please put up a file on ftp.ripe.net containing columns X, Y, and Z?. But I won't stand in the way of requesting it through address policy either. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From Niall.oReilly at ucd.ie Fri Sep 7 10:41:20 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 7 Sep 2012 09:41:20 +0100 Subject: [address-policy-wg] 2012-05 New Draft Document and Impact Analysis Published (Transparency in Address Block Transfers) In-Reply-To: <5049B294.1000604@redpill-linpro.com> References: <20120803123602.2E884200D@mail.sintact.nl> <9218887C-FD2F-40E7-BC04-FDB297373083@steffann.nl> <5046F9DD.9040004@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6EA@SUEX10-mbx-10.ad.syr.edu> <50476314.10307@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220EAAF@SUEX10-mbx-10.ad.syr.edu> <50499D55.5050203@redpill-linpro.com> <72C79BB3-D6D9-4A89-9792-EB644142AEDA@ucd.ie> <5049B294.1000604@redpill-linpro.com> Message-ID: <4CDBF296-6544-4395-99E5-BD3A663420F9@ucd.ie> On 7 Sep 2012, at 09:38, Tore Anderson wrote: > I remain unconvinced that we need to change address policy in order to > get these stats made available, though. It seems more like an NCC > service to me - that it would be better to simply ask the NCC Me too. /Niall From hank at efes.iucc.ac.il Mon Sep 10 08:23:50 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 10 Sep 2012 09:23:50 +0300 Subject: [address-policy-wg] =?iso-8859-1?q?Revert_=93Run_Out_Fairly=94_af?= =?iso-8859-1?q?ter_IPv4__depletion?= In-Reply-To: <855077AC3D7A7147A7570370CA01ECD214187E@SUEX10-mbx-10.ad.sy r.edu> References: <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> Message-ID: <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> > > Dear Colleagues > > > > A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation > > and Assignment Policy for the RIPE NCC Service Region", is now > > available for discussion. > > > > > > You can find the full proposal at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-06 > >I see the noble goal of this proposal - but why bother? Do we have even >enough time for this proposal to become valid policy change according to >all valid rules of PDP? > >http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph > >According to this graph we have one month to go. > >Cheers, Jan Zorz Reading over http://www.ripe.net/ripe/policies/proposals/2012-06 Revert "Run Out Fairly" after IPv4 depletion 5.0 states "As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months." Can someone explain to me how these two recent allocations fit into this rule (extracted from the delegated file): ripencc|IR|ipv4|5.112.0.0|1048576|20120629|allocated ripencc|IR|ipv4|5.208.0.0|1048576|20120904|allocated -Hank From tore.anderson at redpill-linpro.com Mon Sep 10 09:19:09 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 10 Sep 2012 09:19:09 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> References: <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> Message-ID: <504D946D.4070603@redpill-linpro.com> * Hank Nussbacher > Reading over http://www.ripe.net/ripe/policies/proposals/2012-06 > > Revert "Run Out Fairly" after IPv4 depletion > > 5.0 states "As of 1 July 2011, the RIPE NCC will start allocating enough > address space to LIRs to meet their needs for a period of up to three > months." > > Can someone explain to me how these two recent allocations fit into this > rule (extracted from the delegated file): > > ripencc|IR|ipv4|5.112.0.0|1048576|20120629|allocated > ripencc|IR|ipv4|5.208.0.0|1048576|20120904|allocated I'm not exactly sure what you're asking here - is there any reason why they wouldn't ?fit into this rule?? The LIRs in question had probably used over 80% of their current allocations (if they had any), documented their need for IPv4 addresses for the coming three months, and received allocations to cover that need. In other words, there's probably nothing special about them at all. It's still more or less business as usual at the NCC, as we've not yet reached the last /8. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From hank at efes.iucc.ac.il Mon Sep 10 09:28:51 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 10 Sep 2012 10:28:51 +0300 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <504D946D.4070603@redpill-linpro.com> References: <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20120910102742.007507b0@efes.iucc.ac.il> At 09:19 10/09/2012 +0200, Tore Anderson wrote: >* Hank Nussbacher > > > Reading over http://www.ripe.net/ripe/policies/proposals/2012-06 > > > > Revert "Run Out Fairly" after IPv4 depletion > > > > 5.0 states "As of 1 July 2011, the RIPE NCC will start allocating enough > > address space to LIRs to meet their needs for a period of up to three > > months." > > > > Can someone explain to me how these two recent allocations fit into this > > rule (extracted from the delegated file): > > > > ripencc|IR|ipv4|5.112.0.0|1048576|20120629|allocated > > ripencc|IR|ipv4|5.208.0.0|1048576|20120904|allocated > >I'm not exactly sure what you're asking here - is there any reason why >they wouldn't ?fit into this rule?? > >The LIRs in question had probably used over 80% of their current >allocations (if they had any), documented their need for IPv4 addresses >for the coming three months, and received allocations to cover that >need. 1 million IP addresses needed in a 3 month period? Fascinating. -Hank >In other words, there's probably nothing special about them at >all. It's still more or less business as usual at the NCC, as we've not >yet reached the last /8. > >-- >Tore Anderson >Redpill Linpro AS - http://www.redpill-linpro.com/ From tore.anderson at redpill-linpro.com Mon Sep 10 09:43:00 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 10 Sep 2012 09:43:00 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <5.1.1.6.2.20120910102742.007507b0@efes.iucc.ac.il> References: <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <5.1.1.6.2.20120910102742.007507b0@efes.iucc.ac.il> Message-ID: <504D9A04.10801@redpill-linpro.com> * Hank Nussbacher > 1 million IP addresses needed in a 3 month period? Fascinating. Sure, why not? 5.112.0.0/11, for example, seems to be delegated to a mobile operator in a developing country with a population of 75M people. That they need lots of IPv4 addresses should come as no surprise. (Compare the allocations being made in the APNIC area in the time leading up to their free pool depletion.) Your two examples aren't uniquely large, either: ripencc|DE|ipv4|37.80.0.0|1048576|20120124|allocated ripencc|FR|ipv4|37.160.0.0|1048576|20120308|allocated ripencc|FR|ipv4|176.128.0.0|4194304|20110706|allocated Bottom line is - there are about 2.5M addresses left in the NCC's free pool. If you need them all, you can have them all. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From kuenzler at init7.net Mon Sep 10 09:38:39 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Mon, 10 Sep 2012 09:38:39 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <504D946D.4070603@redpill-linpro.com> References: <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504D946D.4070603@redpill-linpro.com> Message-ID: <504D98FF.1020008@init7.net> Am 10.09.2012 09:19, schrieb Tore Anderson: >> 5.0 states "As of 1 July 2011, the RIPE NCC will start allocating >> enough address space to LIRs to meet their needs for a period of up to >> three months." >> >> Can someone explain to me how these two recent allocations fit into >> this rule (extracted from the delegated file): >> >> ripencc|IR|ipv4|5.112.0.0|1048576|20120629|allocated >> ripencc|IR|ipv4|5.208.0.0|1048576|20120904|allocated > > I'm not exactly sure what you're asking here - is there any reason why > they wouldn't ?fit into this rule?? > > The LIRs in question had probably used over 80% of their current > allocations (if they had any), documented their need for IPv4 addresses > for the coming three months, and received allocations to cover that need. > In other words, there's probably nothing special about them at all. It's > still more or less business as usual at the NCC, as we've not yet reached > the last /8. Nope. If you look at the allocation history of the two members which received these /12, I hardly doubt they are actually going to use this space within the next 3 months. One member received a total of less than /14 within two years, and the other member got his last /14 two about years ago. We all know that inflated allocation requests have been common habit in the past in this community but as we are going to run out within weeks or even days I do expect the hostmaster team to watch this with more care, especially when working on large requests. -- Fredy K?nzler Init7 / AS13030 From tore.anderson at redpill-linpro.com Mon Sep 10 10:06:10 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 10 Sep 2012 10:06:10 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <504D98FF.1020008@init7.net> References: <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504D946D.4070603@redpill-linpro.com> <504D98FF.1020008@init7.net> Message-ID: <504D9F72.2060301@redpill-linpro.com> * Fredy Kuenzler > Nope. If you look at the allocation history of the two members which > received these /12, I hardly doubt they are actually going to use this > space within the next 3 months. One member received a total of less than > /14 within two years, and the other member got his last /14 two about > years ago. Neither of us have access to the supporting documentation for either of these two tickets, so this would be pure conjecture on your part. How knows, maybe they both have a million customers behind a CGN they plan on shutting off? > We all know that inflated allocation requests have been common habit in > the past in this community but as we are going to run out within weeks > or even days I do expect the hostmaster team to watch this with more > care, especially when working on large requests. I'm certain that they do. I recall reading or hearing somewhere that allocations of size /16 and larger are approved by a special committee in addition to the resource analyst that processed the request (didn't find a link though), so I feel confident that the NCC isn't arbitrarily giving out more addresses to LIRs than the request justifies. Recently, the resource analysts began working in pairs in order to further minimise the chances of inequality - see . If you have reason to believe one or both of the LIRs in question have committed fraud by forging their documentation, then I suppose that is something you should discuss directly with the NCC. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From emadaio at ripe.net Mon Sep 10 14:16:44 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 10 Sep 2012 14:16:44 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) Message-ID: Dear Colleagues, The draft document for the proposal described in 2012-04 has been published. The impact analysis that was conducted for this proposal has also been published You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-04 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-04/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 8 October. Regards Emilio Madaio Policy Development Officer RIPE NCC From erik at bais.name Mon Sep 10 14:39:29 2012 From: erik at bais.name (Erik Bais) Date: Mon, 10 Sep 2012 14:39:29 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910121712.D7AEAED4580@klant.eznet.nl> References: <20120910121712.D7AEAED4580@klant.eznet.nl> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Dear Emilio & Nick, Thanks for the update on the proposal. I would like to state that I'm not in favor of this policy change. Obviously it is very appealing to open up the last /8 also for end-user assignments, even with the additions of limiting only to a /24 max. But I'm afraid that there will be a run on the last possible addresses and that there won't be any IP space left for new LIR's if they require it. ( Do I even dare to state anything about routing table explosion because of it ? ) For me this is a no-go policy change. IPv4 is over in a couple weeks in the RIPE region. Let's move on. Regards, Erik Bais From lists-ripe at c4inet.net Mon Sep 10 14:52:08 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 10 Sep 2012 13:52:08 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <20120910125208.GA4245@cilantro.c4inet.net> On Mon, Sep 10, 2012 at 02:39:29PM +0200, Erik Bais wrote: >IPv4 is over in a couple weeks in the RIPE region. Let's move on. For this reason alone, I see no major issue with also assigning PI from that final /8... rgds, Sascha Luck From richih.mailinglist at gmail.com Mon Sep 10 14:51:59 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 10 Sep 2012 14:51:59 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: I am in favour of this PDP. On Mon, Sep 10, 2012 at 2:39 PM, Erik Bais wrote: > Obviously it is very appealing to open up the last /8 also for end-user assignments, even with the additions of limiting only to a /24 max. Correct. > But I'm afraid that there will be a run on the last possible addresses and that there won't be any IP space left for new LIR's if they require it. ( Do I even dare to state anything about routing table explosion because of it ? ) Obviously there will be a time when there is no more v4 left. That's the reason for v6. Preventing the fulfillment of current needs by one entity (end customers) in favour of another entity (LIRs) does not make sense, imo. Exchanges are already provided with extra space because they benefit everyone. The last /8 will be fragmented heavily regardless of what we do so I am not sure of how much use preventing this policy change would be inthis regard. > IPv4 is over in a couple weeks in the RIPE region. Let's move on. That's factually incorrect and you know it. v4 will stay around for more than "a couple weeks" and you know it. Arguably, running out earlier is better than running out later. -- Richard From gert at space.net Mon Sep 10 15:10:46 2012 From: gert at space.net (Gert Doering) Date: Mon, 10 Sep 2012 15:10:46 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910125208.GA4245@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120910125208.GA4245@cilantro.c4inet.net> Message-ID: <20120910131046.GF13776@Space.Net> Hi, On Mon, Sep 10, 2012 at 01:52:08PM +0100, Sascha Luck wrote: > On Mon, Sep 10, 2012 at 02:39:29PM +0200, Erik Bais wrote: > >IPv4 is over in a couple weeks in the RIPE region. Let's move on. > > For this reason alone, I see no major issue with also assigning PI > from that final /8... Is that just a remark, or are you speaking in favour of 2012-04? 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 lists-ripe at c4inet.net Mon Sep 10 15:19:16 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 10 Sep 2012 14:19:16 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910131046.GF13776@Space.Net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120910125208.GA4245@cilantro.c4inet.net> <20120910131046.GF13776@Space.Net> Message-ID: <20120910131916.GB4245@cilantro.c4inet.net> On Mon, Sep 10, 2012 at 03:10:46PM +0200, Gert Doering wrote: >> For this reason alone, I see no major issue with also assigning PI >> from that final /8... > >Is that just a remark, or are you speaking in favour of 2012-04? Both. Sorry, should have clarified that. rgds, Sascha Luck From jasper.jans at esprittelecom.nl Mon Sep 10 14:51:50 2012 From: jasper.jans at esprittelecom.nl (Jasper Jans) Date: Mon, 10 Sep 2012 14:51:50 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20131D82C664F@EXCH01.campus.local> I have to agree with Erik. Jasper -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Erik Bais Sent: Monday, September 10, 2012 2:39 PM To: address-policy-wg at ripe.net; Nick Hilliard (nick at inex.ie) Subject: Re: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) Dear Emilio & Nick, Thanks for the update on the proposal. I would like to state that I'm not in favor of this policy change. Obviously it is very appealing to open up the last /8 also for end-user assignments, even with the additions of limiting only to a /24 max. But I'm afraid that there will be a run on the last possible addresses and that there won't be any IP space left for new LIR's if they require it. ( Do I even dare to state anything about routing table explosion because of it ? ) For me this is a no-go policy change. IPv4 is over in a couple weeks in the RIPE region. Let's move on. Regards, Erik Bais Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.esprittelecom.nl/disclaimer/html From marcin at leon.pl Mon Sep 10 15:34:26 2012 From: marcin at leon.pl (marcin at leon.pl) Date: Mon, 10 Sep 2012 15:34:26 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910121651.B261239D23@kameleon.leon.pl> References: <20120910121651.B261239D23@kameleon.leon.pl> Message-ID: On 10.09.2012 14:16, Emilio Madaio wrote: > Dear Colleagues, > > The draft document for the proposal described in 2012-04 has been > published. The impact analysis that was conducted for this proposal > has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-04 Looks good, have my support. Regards, Marcin > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-04/draft > > We encourage you to read the draft document text and send any > comments > to address-policy-wg at ripe.net before 8 October. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC From randy at psg.com Mon Sep 10 15:54:50 2012 From: randy at psg.com (Randy Bush) Date: Mon, 10 Sep 2012 22:54:50 +0900 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: > But I'm afraid that there will be a run on the last possible addresses > and that there won't be any IP space left for new LIR's if they > require it. i can not speak to the intent in the ripe region. but the principal intent of the final /8 policy in the apnic region was so that *new* entrants could get one small piece of the pie. in the years when we have a mixed 6/4 internet, folk will need a wee bit of v4 space for things such as nat64 and other ways face the dual stack world. pissing it away in greed and/or arrogance is not responsible to our children. randy From jasper.jans at esprittelecom.nl Mon Sep 10 16:00:36 2012 From: jasper.jans at esprittelecom.nl (Jasper Jans) Date: Mon, 10 Sep 2012 16:00:36 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66B3@EXCH01.campus.local> +1 -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Randy Bush Sent: Monday, September 10, 2012 3:55 PM To: Erik Bais Cc: Nick Hilliard (nick at inex.ie); address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) > But I'm afraid that there will be a run on the last possible addresses > and that there won't be any IP space left for new LIR's if they > require it. i can not speak to the intent in the ripe region. but the principal intent of the final /8 policy in the apnic region was so that *new* entrants could get one small piece of the pie. in the years when we have a mixed 6/4 internet, folk will need a wee bit of v4 space for things such as nat64 and other ways face the dual stack world. pissing it away in greed and/or arrogance is not responsible to our children. randy Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.esprittelecom.nl/disclaimer/html From erik at bais.name Mon Sep 10 16:12:16 2012 From: erik at bais.name (Erik Bais) Date: Mon, 10 Sep 2012 16:12:16 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586E@EXVS002.netsourcing.lan> Hi Randy, > i can not speak to the intent in the ripe region. but the principal intent of the final /8 policy in the apnic region was so that *new* entrants could get one small piece of the pie. > in the years when we have a mixed 6/4 internet, folk will need a wee bit of v4 space for things such as nat64 and other ways face the dual stack world. > pissing it away in greed and/or arrogance is not responsible to our children. I fully agree with you. My company (A2B Internet) did a lot of PI registrations in the last couple of years and it would be very nice to have this available for a couple more months for possible customers in the next couple months. However, having said that, the reserved space in the final /8 is to allow '*new* entrants' and that is also how I view this. So although it might not be in the best interest for my company (PI registration business wise), I still don't agree with the proposal. Regards, Erik Bais From gert at space.net Mon Sep 10 16:12:21 2012 From: gert at space.net (Gert Doering) Date: Mon, 10 Sep 2012 16:12:21 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66B3@EXCH01.campus.local> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66B3@EXCH01.campus.local> Message-ID: <20120910141221.GN13776@Space.Net> Hi, On Mon, Sep 10, 2012 at 04:00:36PM +0200, Jasper Jans wrote: > +1 Does that mean "I support the policy proposal 2012-04" or "I agree with Randy about the original intent of the last-/8-Policy" or "I oppose 2012-04"? A *few* more words save lots of extra questions. (I took Randy's e-mail as explanation about the last /8 policy, and not voicing a particular opinion on 2012-04. Correct me if that was not right) 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 jasper.jans at esprittelecom.nl Mon Sep 10 16:14:09 2012 From: jasper.jans at esprittelecom.nl (Jasper Jans) Date: Mon, 10 Sep 2012 16:14:09 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910141221.GN13776@Space.Net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66B3@EXCH01.campus.local> <20120910141221.GN13776@Space.Net> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66BB@EXCH01.campus.local> Gert, My apoligies - it is a +1 on Randy's email. Lets reserve the last few ipv4 addresses for those who come in the future and not blow through them quickly. So I do not support the change in policy. Jasper -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Monday, September 10, 2012 4:12 PM To: Jasper Jans Cc: Randy Bush; Erik Bais; Nick Hilliard (nick at inex.ie); address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) Hi, On Mon, Sep 10, 2012 at 04:00:36PM +0200, Jasper Jans wrote: > +1 Does that mean "I support the policy proposal 2012-04" or "I agree with Randy about the original intent of the last-/8-Policy" or "I oppose 2012-04"? A *few* more words save lots of extra questions. (I took Randy's e-mail as explanation about the last /8 policy, and not voicing a particular opinion on 2012-04. Correct me if that was not right) 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 Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.esprittelecom.nl/disclaimer/html From randy at psg.com Mon Sep 10 16:16:24 2012 From: randy at psg.com (Randy Bush) Date: Mon, 10 Sep 2012 23:16:24 +0900 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910141221.GN13776@Space.Net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <55557D0EBE9495428BFE94EF8BC5EBD20131D82C66B3@EXCH01.campus.local> <20120910141221.GN13776@Space.Net> Message-ID: > (I took Randy's e-mail as explanation about the last /8 policy, and > not voicing a particular opinion on 2012-04. Correct me if that was > not right) you are correct. i am not an address holder in the ripe region, despite it's rather amazing span. [ if i was one, i would not support the proposal. ] randy From sander at steffann.nl Mon Sep 10 16:30:10 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Sep 2012 16:30:10 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <06532CA4-C65A-4773-A82A-BEDD84DD6251@steffann.nl> Hi Randy, >> But I'm afraid that there will be a run on the last possible addresses >> and that there won't be any IP space left for new LIR's if they >> require it. > > i can not speak to the intent in the ripe region. but the principal > intent of the final /8 policy in the apnic region was so that *new* > entrants could get one small piece of the pie. This was also the original reasoning here in the RIPE region. - Sander From lists-ripe at c4inet.net Mon Sep 10 17:02:08 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 10 Sep 2012 16:02:08 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <06532CA4-C65A-4773-A82A-BEDD84DD6251@steffann.nl> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <06532CA4-C65A-4773-A82A-BEDD84DD6251@steffann.nl> Message-ID: <20120910150208.GC4245@cilantro.c4inet.net> On Mon, Sep 10, 2012 at 04:30:10PM +0200, Sander Steffann wrote: >> i can not speak to the intent in the ripe region. but the principal >> intent of the final /8 policy in the apnic region was so that *new* >> entrants could get one small piece of the pie. > >This was also the original reasoning here in the RIPE region. If so, the letter of the policy contradicts this - there is no mention of only "new" requestors, rather any LIR that can demonstrate a need will be assigned one last /22. One could reasonably assume that the intention has then failed in the original policy and is not a valid argument against the proposal... rgds, Sascha Luck From richih.mailinglist at gmail.com Mon Sep 10 17:04:11 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 10 Sep 2012 17:04:11 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: On Mon, Sep 10, 2012 at 3:54 PM, Randy Bush wrote: > pissing it away in greed and/or arrogance is not responsible to our > children. There are rational and consistent arguments to be made on either side, please do not imply otherwise. Even though you are not a direct stakeholder, I am sure your factual comments will be appreciated by everyone involved, even if they should happen to disagree. -- Richard From sander at steffann.nl Mon Sep 10 17:07:52 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Sep 2012 17:07:52 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910150208.GC4245@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <06532CA4-C65A-4773-A82A-BEDD84DD6251@steffann.nl> <20120910150208.GC4245@cilantro.c4inet.net> Message-ID: <573BA28D-F791-4953-BAF1-E8A4A2EEFE55@steffann.nl> Hi, >>> i can not speak to the intent in the ripe region. but the principal >>> intent of the final /8 policy in the apnic region was so that *new* >>> entrants could get one small piece of the pie. >> >> This was also the original reasoning here in the RIPE region. > > If so, the letter of the policy contradicts this - there is no mention > of only "new" requestors, rather any LIR that can demonstrate a need > will be assigned one last /22. One could reasonably assume that the intention has then failed in the > original policy and is not a valid argument against the proposal... Correct. That is why I said 'original reasoning'. At some point it was decided (as in: declared consensus on) that existing LIRs also should get some addresses for NATs, proxy servers etc. The RIPE NCC can double in member-count while still being able to give every LIR a /22. But the reason the policy was proposed in the first place was for the new entrants. Met vriendelijke groet, Sander Steffann From nick at inex.ie Mon Sep 10 17:14:37 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 10 Sep 2012 16:14:37 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <504E03DD.3080300@inex.ie> On 10/09/2012 13:39, Erik Bais wrote: > I would like to state that I'm not in favor of this policy change. > > Obviously it is very appealing to open up the last /8 also for end-user > assignments, even with the additions of limiting only to a /24 max. > > But I'm afraid that there will be a run on the last possible addresses > and that there won't be any IP space left for new LIR's if they require > it. ( Do I even dare to state anything about routing table explosion > because of it ? ) Eric, thanks for your comments on this proposal. Your argument is based on the assertion that the IP addressing requirements of a LIR are more important than the requirements of an End User. This point could be argued endlessly - in fact I'd argue that they could be perceived as important in some respects. However your conclusion is that the requirements of End Users are sufficiently insignificant compared to new LIR requirements, that they do not deserve any IPv4 addresses at all from what's left in the pot. This is an extraordinarily discriminatory position. In fact I find it not just to be unfair, but dramatically anti- competitive as the LIRs could be seen as harbouring the remaining IPv4 address space for members of their own club. The counter-argument that anyone can become a LIR is weak because it will enforce that all such organisations are allocated a /22 instead of a /24 regardless of whether they actually need it or not. I would argue that we are very likely to see huge numbers of applications for new LIR membership from spurious organisations after the imminent depletion, which will cause run-out even faster than with 2012-04. A run on address space is inevitable no matter what happens, and we will reach the end of the barrel very shortly indeed. This proposal will not cause a run any more than what is going to happen anyway. It's also important to realise that the term "last /8" is now jargon for "all IPv4 addresses which the RIPE NCC handles after the exhaustion of the second last /8". In other words, it explicitly includes all IP addresses which are recovered by the RIPE NCC in future. By rejecting this proposal, this discrimination against End User requirements will be permanently enshrined in RIPE policy and that they won't get the opportunity to apply for reclaimed address space in future. Again, I find this to compound the implicit unfairness of excluding them in the first place. Nick From erik at bais.name Mon Sep 10 17:23:11 2012 From: erik at bais.name (Erik Bais) Date: Mon, 10 Sep 2012 17:23:11 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910150208.GC4245@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <06532CA4-C65A-4773-A82A-BEDD84DD6251@steffann.nl> <20120910150208.GC4245@cilantro.c4inet.net> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586F@EXVS002.netsourcing.lan> Hi Sascha, > On Mon, Sep 10, 2012 at 04:30:10PM +0200, Sander Steffann wrote: >> i can not speak to the intent in the ripe region. but the principal >> intent of the final /8 policy in the apnic region was so that *new* >> entrants could get one small piece of the pie. > >This was also the original reasoning here in the RIPE region. > If so, the letter of the policy contradicts this - there is no mention of only "new" requestors, rather any LIR that can demonstrate a need will be assigned one last /22. > One could reasonably assume that the intention has then failed in the original policy and is not a valid argument against the proposal... As I understood the policy, is that it isn't only for new LIR's but there is also a reservation for each current LIR. 5.6 Use of last /8 for PA Allocations 1.Allocations for LIRs from the last /8 On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: 1.LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22. So there is no difference between what a new LIR or a current LIR will receive. As there is only the final /8 soon, new LIR members will get their /22 and that's it. The final /8 does however provide sufficient growth (more than double in numbers of LIR members if I recall correctly) for new LIR members. Regards, Erik Bais From lists-ripe at c4inet.net Mon Sep 10 17:34:51 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 10 Sep 2012 16:34:51 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504E03DD.3080300@inex.ie> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> Message-ID: <20120910153451.GD4245@cilantro.c4inet.net> On Mon, Sep 10, 2012 at 04:14:37PM +0100, Nick Hilliard wrote: >This is an extraordinarily discriminatory position. > >In fact I find it not just to be unfair, but dramatically anti- competitive >as the LIRs could be seen as harbouring the remaining IPv4 address space >for members of their own club. Good point, if someone were to take that to court or the competition commissar. >By rejecting this proposal, this discrimination against End User >requirements will be permanently enshrined in RIPE policy and that they >won't get the opportunity to apply for reclaimed address space in future. >Again, I find this to compound the implicit unfairness of excluding them in >the first place. Possible compromise: make *returned/reclaimed* PI assignments available for assignment as PI rather than using them to make up patchwork PA allocations... rgds, Sascha Luck From erik at bais.name Mon Sep 10 17:40:47 2012 From: erik at bais.name (Erik Bais) Date: Mon, 10 Sep 2012 17:40:47 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504E03DD.3080300@inex.ie> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5870@EXVS002.netsourcing.lan> Hi Nick, > It's also important to realise that the term "last /8" is now jargon for "all IPv4 addresses which the RIPE NCC handles after the exhaustion of the second last /8". > In other words, it explicitly includes all IP addresses which are recovered by the RIPE NCC in future. > By rejecting this proposal, this discrimination against End User requirements will be permanently enshrined in RIPE policy and that they won't get the opportunity to apply for reclaimed address space in future. > Again, I find this to compound the implicit unfairness of excluding them in the first place. The change in the policy is for assignments from the last /8. If the policy would state that PI assignments are still possible from reclaimed address space (but not from the final /8 - the 185.x.x.x/8 range) I might reconsider. In the current form I do not agree with the proposal. Erik From richih.mailinglist at gmail.com Mon Sep 10 17:43:30 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 10 Sep 2012 17:43:30 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910153451.GD4245@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> <20120910153451.GD4245@cilantro.c4inet.net> Message-ID: On Mon, Sep 10, 2012 at 5:34 PM, Sascha Luck wrote: > Possible compromise: make *returned/reclaimed* PI assignments available > for assignment as PI rather than using them to make up patchwork PA > allocations... Let's explore that _if_ 2012-04 is rejected, not now. -- Richard From andrea at ripe.net Mon Sep 10 17:35:42 2012 From: andrea at ripe.net (Andrea Cima) Date: Mon, 10 Sep 2012 17:35:42 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> References: <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> Message-ID: <504E08CE.1040901@ripe.net> Dear all, Regarding the comments on allocations in the run-up to reaching the last /8, we would like to assure you that all requests are met with the highest level of care and due diligence. We do not make public the details of specific requests or the documentation provided by our members, but we are happy to explain the procedures used when evaluating these requests. All allocations and assignments are evaluated in accordance with RIPE Policy and full documentation is required before a request is approved. The relevant policies are listed in ripe-556, "Due Diligence for the Quality of the RIPE NCC Registration Data": https://www.ripe.net/ripe/docs/ripe-556 By default, all large Internet resource requests (/15 or larger for PA IPv4, /18 or larger for PI IPv4 and /28 or larger for IPv6) are evaluated by: - Two IP Resource Analysts (IPRAs) - The Registration Services Manager - The Policy Development Officer - At least two Senior Managers In Phase 1 of reaching the last /8, every request for IPv4 address space is evaluated by two IPRAs, regardless of the size of the request. We would also like to note that requests for IPv4 address space are handled in strict order of receipt by the next available IPRA. Further information on the procedures followed by the RIPE NCC to ensure correct and consistent evaluations of resource requests is available at: http://www.ripe.net/internet-coordination/ipv4-exhaustion/last-8-phases http://ripe64.ripe.net/presentations/168-NCC-Services-final.pdf http://ripe63.ripe.net/presentations/137-end-game.pdf If you have any questions on the RIPE NCC's procedures in the run-up to reaching the last /8, please feel free to contact me. Best regards, Andrea Cima Registration Services RIPE NCC From tore.anderson at redpill-linpro.com Mon Sep 10 17:51:36 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 10 Sep 2012 17:51:36 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <504E0C88.7000602@redpill-linpro.com> * Randy Bush > i can not speak to the intent in the ripe region. but the principal > intent of the final /8 policy in the apnic region was so that *new* > entrants could get one small piece of the pie. > > in the years when we have a mixed 6/4 internet, folk will need a wee bit > of v4 space for things such as nat64 and other ways face the dual stack > world. > > pissing it away in greed and/or arrogance is not responsible to our > children. Hi Randy, and thanks for bringing up the equivalent APNIC region policy. That is definitively relevant to this discussion. I doubt that allowing organisations to be greedy is the intention of 2012-04, it is rather to also allow non-LIRs to get ?a wee bit of v4 space? from the last /8. Currently, this is set aside for LIRs only (both existing and new). Looking at the latest delegated stats file from APNIC, there appears to have been made 510 assignments out of 103/8. They are listed with ?ASSIGNED PORTABLE? in whois, which I believe is the equivalent of ?ASSIGNED PI? in RIPE land? So it is my understanding that 2012-04 would actually make the RIPE ?last /8 policy? more similar to the APNIC one than it currently is. With 2012-04 in place, the largest remaining difference that I could see would be that in the APNIC region assignments up to /22 would be allowed, while in the RIPE region they would be capped at /24 (unlike LIR allocations, which would be capped at /22 - same as APNIC). That said, the ?run on the bank? scenario that Erik was concerned about might turn out to be much worse in the RIPE region than in the APNIC region in spite of this. It is my understanding - please correct me if I'm wrong - that in order to get an assignment out of APNIC's last /8, you'll have to become an APNIC member, which currently costs at least AU$1180/year (~?955). If 2012-04 passes, a RIPE region organisation could grab its last /8 piece for ?50/year without becoming a RIPE NCC member, which is much less of a barrier. Considering the current pricing and membership structures, getting an last /8 assignment from APNIC is perhaps more comparable to becoming a RIPE region LIR, getting the last /8 allocation, and then make a single assignment to its own infrastructure - which is obviously always an option for an organisation seeking IPv4 address space. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From gert at space.net Mon Sep 10 19:55:08 2012 From: gert at space.net (Gert Doering) Date: Mon, 10 Sep 2012 19:55:08 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5870@EXVS002.netsourcing.lan> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5870@EXVS002.netsourcing.lan> Message-ID: <20120910175508.GU13776@Space.Net> Hi, On Mon, Sep 10, 2012 at 05:40:47PM +0200, Erik Bais wrote: > The change in the policy is for assignments from the last /8. > > If the policy would state that PI assignments are still possible from reclaimed address space (but not from the final /8 - the 185.x.x.x/8 range) I might reconsider. > > In the current form I do not agree with the proposal. Noted, and we might want your input in wording this accordingly, if this is the compromise we can eventually agree on :-) The whole wording surrounding the "last /8" policy in the current documents has caused quite a bit of confusion in the past - but indeed it was agreed by the WG that as soon as this policy goes into effect, it's lasting, and "the last /8" will be "all of it, after the threshold has been crossed once"... 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 farmer at umn.edu Mon Sep 10 21:24:37 2012 From: farmer at umn.edu (David Farmer) Date: Mon, 10 Sep 2012 14:24:37 -0500 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910153451.GD4245@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> <20120910153451.GD4245@cilantro.c4inet.net> Message-ID: <504E3E75.2090604@umn.edu> On 9/10/12 10:34 CDT, Sascha Luck wrote: > On Mon, Sep 10, 2012 at 04:14:37PM +0100, Nick Hilliard wrote: ... >> By rejecting this proposal, this discrimination against End User >> requirements will be permanently enshrined in RIPE policy and that they >> won't get the opportunity to apply for reclaimed address space in future. >> Again, I find this to compound the implicit unfairness of excluding >> them in >> the first place. > > Possible compromise: make *returned/reclaimed* PI assignments available > for assignment as PI rather than using them to make up patchwork PA > allocations... Note that besides addresses returned or reclaimed by RIPE there is the Recovered IPv4 Pool administered by the IANA, see the global policy [GPP-IPv4-2011, AKA RIPE-2011-01]; http://www.icann.org/en/news/in-focus/global-addressing/allocation-ipv4-post-exhaustion And it has more than a /8 in it already; https://www.arin.net/announcements/2012/20120611.html So there are going to be dribs and drabs of IPv4 for a long time. (For those not familiar with the idiom "dribs and drabs", it means "small sporadic amounts.") There will not be enough to really make a fundamental difference, however there will definitely be more than enough for people to argue over, its human nature and is already happening. As I don't represent any resources in the RIPE region, I will not express an opinion on the policy itself. But I though it was import for people to realize there is more than a trivial amount of resources in the IANA Recovered IPv4 Pool even though it won't save the world from IPv4 exhaustion either. -- =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From nick at inex.ie Mon Sep 10 23:12:27 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 10 Sep 2012 22:12:27 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504E3E75.2090604@umn.edu> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> <20120910153451.GD4245@cilantro.c4inet.net> <504E3E75.2090604@umn.edu> Message-ID: <504E57BB.2070903@inex.ie> On 10/09/2012 20:24, David Farmer wrote: > So there are going to be dribs and drabs of IPv4 for a long time. There will be dribs and drabs until the heat death of the universe. This will happen because there are garbage collection mechanisms built into the policies of all the RIRs, and every time an organisation or person disappears in such a way that there is no clear succession (e.g. bankruptcy, death, etc), the address space will eventually make its way back to IANA. > As I don't represent any resources in the RIPE region, I will not express > an opinion on the policy itself. But I though it was import for people to > realize there is more than a trivial amount of resources in the IANA > Recovered IPv4 Pool even though it won't save the world from IPv4 > exhaustion either. This is part of the reason that this policy is important. The quantities are small in the scale of things, but the largest arguments are usually about the smallest things. We need policy clarity and some semblance of fairness in how these resources should be divvied up in future. Otherwise it will be to the detriment of the RIPE community in future. Nick From tore.anderson at redpill-linpro.com Tue Sep 11 09:46:55 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 09:46:55 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910121709.8791E1DCF37@mailhub.linpro.no> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> Message-ID: <504EEC6F.1020303@redpill-linpro.com> * Emilio Madaio > The draft document for the proposal described in 2012-04 has been > published. The impact analysis that was conducted for this proposal > has also been published In principle, I support this proposal. Reserving the last /8 to the ?LIR clique? is unfair to End Users who are not LIRs, but who may very well have an equally justifiable demand for IPv4 addresses as any LIR. In fact, I feel that the proposal does not go far enough - in my opinion, both LIRs and End Users should be able to get the same amount of address space from the last /8. I note that in the APNIC region, LIRs and End Users can both get up to a /22 from the last /8. I would prefer it if this was the case in the RIPE region as well. That said, I do fear the practical consequences of this proposal. As the possibility to get PA assignments will be dwindling, End Users may look to PI (quite possibly guided there by their ISP who can be a sponsoring LIR). The current difference in pricing between PI and PA address space is a key element of my worry here - a PI assignment costs ?50/year, while becoming a LIR and getting the PA /22 would under the proposed 2012 charging scheme cost ?1750 (?1000 sign-up fee + ?750 yearly fee). In other words, acquiring PA address space is almost nine times as expensive as PI address space. Furthermore End Users may feel it compelling to set up several legal organisations in order to acquire multiple PI assignments from the last /8. This problem is nothing new - under the current policy, an organisation may set up multiple LIRs and receive multiple /22s from the last /8, but the expense of RIPE NCC membership is likely balancing out the cost/benefit assessment. The cost of PI address space, on the other hand, is too small to be a disincentive. I also note that the Impact Analysis warns that this policy may lead to increased fees for members, which would be an undesirable consequence. I don't feel that the members should be sponsoring the non-members; equal access to addresses from the last /8 should mean equal monetary contribution to the NCC. So to sum up - I feel that PI assignments should be allowed from the last /8. However, if they are, I strongly feel that they should be priced more or less the same (per address) as getting an allocation from the last /8 through first becoming an LIR. That said, I don't know if APWG have any influence on the NCC's charging scheme at all. Is it possible for this policy to say something along the lines of ?joining the NCC and obtaining a PA allocation from the last /8 should cost approximately the same per address as obtaining a PI assignment from the last /8?? Is that in scope of address policy? (Just to be clear: I am not stating neither support or opposition to the proposal.) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From erik at bais.name Tue Sep 11 10:04:40 2012 From: erik at bais.name (Erik Bais) Date: Tue, 11 Sep 2012 10:04:40 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EEC6F.1020303@redpill-linpro.com> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5871@EXVS002.netsourcing.lan> Hi Tore, The cost for services is something that isn't discussed on the APWG, but on the member-discuss mailinglist. Cost changes are to be decided in the (RIPE meeting) AGM meeting and the current cost for a LIR sign-up is 2000 euro setup and 1300 yearly maintenance. It is not possible to change the cost for LIR sponsored PI via a policy. > I also note that the Impact Analysis warns that this policy may lead to increased fees for members, which would be an undesirable consequence. I don't feel that the members should be sponsoring the non-members; equal access to addresses from the last /8 should mean equal monetary contribution to the NCC. Does that mean that you want the sponsored PI assignments get the same cost as a direct assignment (1300 euro yearly maintenance per object) ? Snip from your email: > In principle, I support this proposal. > (Just to be clear: I am not stating neither support or opposition to the proposal.) Which one is it? Regards, Erik Bais From gert at space.net Tue Sep 11 10:11:38 2012 From: gert at space.net (Gert Doering) Date: Tue, 11 Sep 2012 10:11:38 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EEC6F.1020303@redpill-linpro.com> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> Message-ID: <20120911081138.GZ13776@Space.Net> Hi, On Tue, Sep 11, 2012 at 09:46:55AM +0200, Tore Anderson wrote: > That said, I don't know if APWG have any influence on the NCC's charging > scheme at all. Is it possible for this policy to say something along the > lines of ?joining the NCC and obtaining a PA allocation from the last /8 > should cost approximately the same per address as obtaining a PI > assignment from the last /8?? Is that in scope of address policy? APWG can voice an opinion, but that has no legal binding - the fees are decided (voted!) by the paying members in the RIPE NCC general meeting (AGM). So while the NCC board may listen to us (and usually does), and propose a corresponding fee structure, if the members vote against it, APWG has no way to force anything. 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 andreas.larsen at ip-only.se Tue Sep 11 10:17:07 2012 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 11 Sep 2012 10:17:07 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: Message-ID: I do NOT support this change. // Andreas Den 2012-09-10 14:16 skrev Emilio Madaio : > > > >Dear Colleagues, > >The draft document for the proposal described in 2012-04 has been >published. The impact analysis that was conducted for this proposal >has also been published > > >You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-04 > >and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-04/draft > >We encourage you to read the draft document text and send any comments >to address-policy-wg at ripe.net before 8 October. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > From tore.anderson at redpill-linpro.com Tue Sep 11 10:21:01 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 10:21:01 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5871@EXVS002.netsourcing.lan> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5871@EXVS002.netsourcing.lan> Message-ID: <504EF46D.2080108@redpill-linpro.com> * Erik Bais >> I also note that the Impact Analysis warns that this policy may >> lead to increased fees for members, which would be an undesirable >> consequence. I don't feel that the members should be sponsoring the >> non-members; equal access to addresses from the last /8 should mean >> equal monetary contribution to the NCC. > > Does that mean that you want the sponsored PI assignments get the > same cost as a direct assignment (1300 euro yearly maintenance per > object) ? Yes, something along those lines would be good. BTW: This would, as I understand it, be in the same ballpark as what you would have to pay if you want a PI assignment from APNIC's last /8. > Snip from your email: > >> In principle, I support this proposal. > >> (Just to be clear: I am not stating neither support or opposition >> to the proposal.) > > Which one is it? Neither. I haven't made up my mind yet, so I'm thinking out loud... -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From dr at cluenet.de Tue Sep 11 10:15:54 2012 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 11 Sep 2012 10:15:54 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910121706.073E0108616@mail1.cluenet.de> References: <20120910121706.073E0108616@mail1.cluenet.de> Message-ID: <20120911081554.GA22611@srv03.cluenet.de> On Mon, Sep 10, 2012 at 02:16:44PM +0200, Emilio Madaio wrote: > https://www.ripe.net/ripe/policies/proposals/2012-04/draft I do fully support this proposal. Thanks Nick for bringing up that issue which I missed when the last-/8 policy proposal was on the table. To those who ask for "same price tag" for both PA and PI on grounds of "fairness"... What is fair in asking the same price for what is essentially a one-time operation (PI assignment) compared to the ongoing maintenance of a LIR membership (PA alloc - think about assignment request tickets, yearly billing, etc.)? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From erik at bais.name Tue Sep 11 10:27:29 2012 From: erik at bais.name (Erik Bais) Date: Tue, 11 Sep 2012 10:27:29 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EF46D.2080108@redpill-linpro.com> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5871@EXVS002.netsourcing.lan> <504EF46D.2080108@redpill-linpro.com> Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5872@EXVS002.netsourcing.lan> Hi Tore, >>> I also note that the Impact Analysis warns that this policy may lead >> >to increased fees for members, which would be an undesirable >> >consequence. I don't feel that the members should be sponsoring the >> >non-members; equal access to addresses from the last /8 should mean >> >equal monetary contribution to the NCC. > >> Does that mean that you want the sponsored PI assignments get the same >> cost as a direct assignment (1300 euro yearly maintenance per >> object) ? >Yes, something along those lines would be good. Perhaps an easier way of dealing with something like a price point or cost in that case, is to not allow LIR Sponsored IPv4 PI from the last /8. Which would result in only having the option of either becoming a LIR or sign a direct end-user agreement with RIPE. Regards, Erik From rg at teamix.de Tue Sep 11 10:29:14 2012 From: rg at teamix.de (Rico Gloeckner) Date: Tue, 11 Sep 2012 10:29:14 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EEC6F.1020303@redpill-linpro.com> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> Message-ID: <20120911082914.GB15573@teamix.net> Hi, On Tue, Sep 11, 2012 at 09:46:55AM +0200, Tore Anderson wrote: > That said, I do fear the practical consequences of this proposal. As the > possibility to get PA assignments will be dwindling, End Users may look > to PI (quite possibly guided there by their ISP who can be a sponsoring > LIR). The current difference in pricing between PI and PA address space > is a key element of my worry here - a PI assignment costs ?50/year, > while becoming a LIR and getting the PA /22 would under the proposed > 2012 charging scheme cost ?1750 (?1000 sign-up fee + ?750 yearly fee). > In other words, acquiring PA address space is almost nine times as > expensive as PI address space. I'm not sure wether the multihoming requirement is for piv4 or piv6, but i think this may help. Multihoming would raise the financial bar further, in that it needs more/other infrastructure to actually use the PI. OTOH i strongly suspect that the ease of setting up a lir and getting a flat /22 will outweigh the effort of setting up four organizations to get four (possibly split) /24 PI. If what other people suggest comes true (in terms of "selling ip space"), i also believe the financial expense of becoming lir will rather be a small value in the bigger equation. That said i feel the document should speak of "Direct Assignments", and not "Assignments to Endusers", because i dont see how the latter wording would not apply to ASSIGNED PA, also (even if it doesnt "make sense" to apply it that way) - it doesnt hurt to add the word, on the other hand it makes the intent more clear. (abstention) Rico MfG/regards, -- Rico Gloeckner Sr. System Engineer teamix GmbH Suedwestpark 35 90449 Nuernberg Amtsgericht Nuernberg, HRB 18320 Geschaeftsfuehrer: Oliver Kuegow, Richard Mueller From gert at space.net Tue Sep 11 10:51:55 2012 From: gert at space.net (Gert Doering) Date: Tue, 11 Sep 2012 10:51:55 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120911082914.GB15573@teamix.net> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> <20120911082914.GB15573@teamix.net> Message-ID: <20120911085155.GB13776@Space.Net> Hi, On Tue, Sep 11, 2012 at 10:29:14AM +0200, Rico Gloeckner wrote: > I'm not sure wether the multihoming requirement is for piv4 or piv6 > [...] Neither, actually. For IPv4, *if* you multihome, you can round up your address needs up to the next /24 boundary. If you're singlehomed, you have to document the need for the full /24, or you get a smaller network "needs based" (which might be sufficient to number some sort of corporate VPN DMZ or such, to be never routed on the public Internet). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tore.anderson at redpill-linpro.com Tue Sep 11 10:52:10 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 10:52:10 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120911081554.GA22611@srv03.cluenet.de> References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> Message-ID: <504EFBBA.70601@redpill-linpro.com> * Daniel Roesen > To those who ask for "same price tag" for both PA and PI on grounds of > "fairness"... What is fair in asking the same price for what is > essentially a one-time operation (PI assignment) compared to the ongoing > maintenance of a LIR membership (PA alloc - think about assignment > request tickets, yearly billing, etc.)? The comparsion I'm making is between an organistion that either: * Joins the NCC - becomes a LIR * Makes 1 initial allocation request - gets a /22 * Makes 1 PA assignment request (to itself) Cost: ?1750 Or: * Makes 1 PI assignment request [through a sponsoring LIR] Cost: ?50 I don't believe that the current prices are ?fair? either. While the first option is certainly means work for the NCC, I doubt it is 35 times the work. The resource is scarce - it is impossible to accomplish ?fair?. In any case, the reason why I'd like PI and PA to cost about the same is that 2012-04 with the current pricing structure would mean it is too easy and cheap for an organisation to work around the ?max a /24? limitation. I could trivially set up legal entities like so: * ToreISP Main Street 1-80 Oslo * ToreISP Main Street 81-120 Oslo * ToreISP Grand Avenue 20-35 Stockholm ...and so on, and get all the PI /24s I need. The organisations that are actually NCC members will end up sponsoring me, too - potentially ending up with even higher membership fees, as the Impact Analysis points out. It may be circumenting policy, but I don't think there's any way to stop it. (The NCC mentions this in the Impact Analysis, too.) That's why I think there must be a financial disincentive against doing so, and ?50 doesn't cut it. I'll end with an example of something similar already taking place: Under .no, a single organisation can only register 100 domains. Which leads to organisations such as these: http://w2.brreg.no/enhet/sok/treffliste.jsp?navn=edda+domene This isn't the work of a shady domain pirate/squatter either, Edda a very large and respected media/publishing conglomerate here. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From lists-ripe at c4inet.net Tue Sep 11 12:05:22 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 11 Sep 2012 11:05:22 +0100 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EFBBA.70601@redpill-linpro.com> References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> Message-ID: <20120911100522.GA11349@cilantro.c4inet.net> On Tue, Sep 11, 2012 at 10:52:10AM +0200, Tore Anderson wrote: >* Joins the NCC - becomes a LIR >* Makes 1 initial allocation request - gets a /22 >* Makes 1 PA assignment request (to itself) > >Cost: ?1750 > >Or: > >* Makes 1 PI assignment request [through a sponsoring LIR] > >Cost: ?50 But they can do this now. In fact it's always been possible to game that system, regardless of ipv4 run-out. Assuming this is not a widespread problem now, why would it become one? rgds, Sascha Luck From tore.anderson at redpill-linpro.com Tue Sep 11 13:02:41 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 13:02:41 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120911100522.GA11349@cilantro.c4inet.net> References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> Message-ID: <504F1A51.7040206@redpill-linpro.com> * Sascha Luck > On Tue, Sep 11, 2012 at 10:52:10AM +0200, Tore Anderson wrote: >> * Joins the NCC - becomes a LIR >> * Makes 1 initial allocation request - gets a /22 >> * Makes 1 PA assignment request (to itself) >> >> Cost: ?1750 >> >> Or: >> >> * Makes 1 PI assignment request [through a sponsoring LIR] >> >> Cost: ?50 > > But they can do this now. In fact it's always been possible to game that > system, regardless of ipv4 run-out. Assuming this is not a widespread > problem now, why would it become one? Precisely because of IPv4 depletion. Say you're an ISP who needs a /16. Today, you can have it - and there's no reason to game the system. However, after the last /8 policy hits, you can't get this space from the NCC unless you either (assuming 2012-04 passes): A) join the NCC with 64 LIRs, each getting a /22 allocation at a total cost of ?112.000, or B) get 256 /24 PI assignments at a price of ?12.800. The B option is actually affordable. At ?0.20 per address, it's way cheaper than what Microsoft paid for the second-hand Nortel addresses, for instance (US$11.25 per address IIRC). -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From richih.mailinglist at gmail.com Tue Sep 11 13:26:03 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 11 Sep 2012 13:26:03 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504F1A51.7040206@redpill-linpro.com> References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> <504F1A51.7040206@redpill-linpro.com> Message-ID: You would need to have 256 companies for this. This, in turn, generates significant cost when compared to 64 companies. 64 LIRs give voting power, as well. Is this scenario realistic? Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jblessing at llnw.com Tue Sep 11 13:25:42 2012 From: jblessing at llnw.com (James Blessing) Date: Tue, 11 Sep 2012 12:25:42 +0100 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504F1A51.7040206@redpill-linpro.com> References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> <504F1A51.7040206@redpill-linpro.com> Message-ID: On 11 September 2012 12:02, Tore Anderson wrote: > A) join the NCC with 64 LIRs, each getting a /22 allocation at a total > cost of ?112.000, or > B) get 256 /24 PI assignments at a price of ?12.800. > > The B option is actually affordable. At ?0.20 per address, it's way > cheaper than what Microsoft paid for the second-hand Nortel addresses, > for instance (US$11.25 per address IIRC). and option A is less than e2.00 per year so excellent value for money if you compare it to the MS price J -- James Blessing +44 7989 039 476 Strategic Relations Manager, EMEA Limelight Networks From frettled at gmail.com Tue Sep 11 13:45:41 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 11 Sep 2012 13:45:41 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> <504F1A51.7040206@redpill-linpro.com> Message-ID: On Tue, Sep 11, 2012 at 1:26 PM, Richard Hartmann < richih.mailinglist at gmail.com> wrote: > You would need to have 256 companies for this. This, in turn, generates > significant cost when compared to 64 companies. 64 LIRs give voting power, > as well. > > Is this scenario realistic? > Yes, as Tore already explained, this strategy has already been successfully used for registering .no domains beyond the registry imposed limit. Registering a .no domain costs merely 20? or so, and until this year, there was a cap at 20 registrations per organization. Feel free to ask the owners of Domene Klubben 1 through 442 if the inconvenience of registering 441 extra organizations was too much, even with all the manual paperwork needed back when they formed in 2000. In the case of IP addresses, the cost savings are significant enough that the bother of registering a few hundred extra organizations shouldn't be too bad. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Tue Sep 11 13:49:45 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 13:49:45 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> <504F1A51.7040206@redpill-linpro.com> Message-ID: <504F2559.6080205@redpill-linpro.com> * Richard Hartmann > You would need to have 256 companies for this. This, in turn, > generates significant cost when compared to 64 companies. 64 LIRs > give voting power, as well. > > Is this scenario realistic? I suppose it depends on how complicated it is to register a legal entity, which probably varies greatly from country to country. In Norway, it is very simple and to the best of my knowledge does not cost anything. Or, as the NCC puts it: ?It is also relatively straightforward in many jurisdictions to set up a separate legal entity that could then apply for a PI assignment, resulting in one actual organisation holding multiple /24s from the last /8.? Considering that registering multiple legal entities to circumvent restrictions on how many .no domain names a single one can hold is already happening -- yes, I do think it is a realistic scenario for acquiring IPv4 as well (perhaps even more so). Registering 192 extra legal entities in order to save ?100K is a no-brainer, if you ask me - even when taking into account the lost voting rights. I'm guessing that an organisation that would do something like is motivated by desperation for IPv4 addresses, rather than a desire to participate in the RIPE community or NCC membership. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson at redpill-linpro.com Tue Sep 11 13:54:45 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 11 Sep 2012 13:54:45 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121706.073E0108616@mail1.cluenet.de> <20120911081554.GA22611@srv03.cluenet.de> <504EFBBA.70601@redpill-linpro.com> <20120911100522.GA11349@cilantro.c4inet.net> <504F1A51.7040206@redpill-linpro.com> Message-ID: <504F2685.30805@redpill-linpro.com> * James Blessing > On 11 September 2012 12:02, Tore Anderson > wrote: > >> A) join the NCC with 64 LIRs, each getting a /22 allocation at a total >> cost of ?112.000, or >> B) get 256 /24 PI assignments at a price of ?12.800. >> >> The B option is actually affordable. At ?0.20 per address, it's way >> cheaper than what Microsoft paid for the second-hand Nortel addresses, >> for instance (US$11.25 per address IIRC). > > and option A is less than e2.00 per year so excellent value for money > if you compare it to the MS price Absolutely. I don't dispute that this can happen the ?multiple LIRs? way, regardless of 2012-04. My worry is mainly that 2012-04, when combined with the current pricing model, will greatly exacerbate the problem. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From sander at steffann.nl Tue Sep 11 14:02:10 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 11 Sep 2012 14:02:10 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: Message-ID: Hello Andreas, > I do NOT support this change. Thank you for your reply. Because this working group works on the basis of consensus it is important to know *why* you don't support this policy proposal though. Can you please elaborate a bit? Thank you! Sander Steffann APWG co-chair From Woeber at CC.UniVie.ac.at Tue Sep 11 15:52:03 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 11 Sep 2012 15:52:03 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120910175508.GU13776@Space.Net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <504E03DD.3080300@inex.ie> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D5870@EXVS002.netsourcing.lan> <20120910175508.GU13776@Space.Net> Message-ID: <504F4203.4080102@CC.UniVie.ac.at> Gert Doering wrote: > Hi, > > On Mon, Sep 10, 2012 at 05:40:47PM +0200, Erik Bais wrote: [...] >>In the current form I do not agree with the proposal. Let me chime in here with the same statement, but emphasising the *in the current form* and let me add *in the current IPv4 policy framework/environment* > Noted, and we might want your input in wording this accordingly, if > this is the compromise we can eventually agree on :-) Here's _my_ reasoning: - in priciple I do see the arguments in favour and I tend to sympathise with them, because this would - potentially - remove an "unfair" imbalance, and there were substantial discussions already towards removing the distinction between PA and PI. but - as the proposal is worded right now, we would add more "special cases" and, as it was pointed out already, financial uncertainties or new and creative, business incentives. - if my information is correct, then addresses from the L/8 would *not* be restricted when it comes to transfers! This may just add inentives to grab addresses from the L/8 and sell^Wtansfer others from one's pool. [ Btw. this issue is already there, without 2012-04 passing. ] > The whole wording surrounding the "last /8" policy in the current documents > has caused quite a bit of confusion in the past - but indeed it was agreed > by the WG that as soon as this policy goes into effect, it's lasting, and > "the last /8" will be "all of it, after the threshold has been crossed > once"... - exactly, and as I was already chastised for pointing out some of the omissions, imbalances and weirdnesses of the already existing policies (in a different discussion thread), while the substrate and the interpretation or validity of the "original intents" is not stable, > Gert Doering > -- APWG chair I do not see any other option for me than stating my *non-support* for this proposal. Going forward with this one, without amending some others at the same time, would just make the patchwork system approach worse and put us deeper into the ditch. I would be more than happy to change my position, as soon as there is a holistic attempt to improve the overall consitency of the different (existing) policies and the concurrently active proposals. Wilfried From tore.anderson at redpill-linpro.com Wed Sep 12 09:19:02 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Wed, 12 Sep 2012 09:19:02 +0200 Subject: [address-policy-wg] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <504EEC6F.1020303@redpill-linpro.com> References: <20120910121709.8791E1DCF37@mailhub.linpro.no> <504EEC6F.1020303@redpill-linpro.com> Message-ID: <50503766.9050501@redpill-linpro.com> * Tore Anderson > (Just to be clear: I am not stating neither support or opposition to the > proposal.) I've slept on it, and I support this proposal. Allowing End Users access to the last /8 is, in my opinion, "The Right Thing To Do". While I think the low cost of PI space compared to PA space is going to cause a high risk for abuse/circumvention of the "one piece each" restriction, this is ultimately something that needs to be solved outside of address policy. If a new version of the proposal is going to be spun, I have the following suggestions for modifications: 1) The proposal should ?voice an opinion?, as Gert put it, that the fees for obtaining a PI prefix from the last /8 should be comparable to obtaining a PA one through becoming a LIR. I hope that this would make it less likely that the "one piece each" restriction would be abused/circumvented - at least, not more likely than the current restriction being circumvented through multiple LIRs. 2) The /24 limit for assignments should be raised to /22. While the current proposal does reduce discrimination of End Users compared to LIRs, it does not remove it completely. I believe that "Doing The Right Thing" would be to make access to the last /8 completely equal, instead of continuing to give preferential treatment to LIRs. As I've pointed out earlier, both of those amendments would make the RIPE last /8 policy (and pricing) more aligned with APNIC's, which appears to work fine for them. They've used 8.7% of their last /8 over the 17 months it's been since they ran out. As I understand it, in their last /8 policy, assignments and allocations are both capped at /22. Regardless of it being an assignment or an allocation, it costs the same - and significantly more than the RIPE ?50: http://www.apnic.net/services/become-a-member/how-much-does-it-cost http://submit.apnic.net/cgi-bin/feecalc.pl?ipv4=%2F22&ipv6=&action=Calculate Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From millnert at gmail.com Fri Sep 14 12:57:28 2012 From: millnert at gmail.com (Martin Millnert) Date: Fri, 14 Sep 2012 12:57:28 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... Message-ID: <1347620248.4301.70.camel@galileo.millnert.se> Hi, I'm looking at https://www.ripe.net/lir-services/resource-management/tools-for-lirs/reponse-time-ipv4 and jump to the conclusion that we're now in final /8 policy land, and IPRAs are out drinking. Whether this conclusion is indeed correct is irrelevant, we at close of business yesterday had 830k remaining addresses above final /8,/13. For those that are not clear on the policy on when final /8 will get enacted, the answer is: as soon as a request is approved that will run into final /8 space to fulfill (ie. minimum a /12, today), final /8 policy will get triggered *before* this allocation is made, and the requestor in question gets the first /22 from the final /8 (if PA request) otherwise nothing (if PI). (consensus from an IRC channel) With that out of the way, there are then no more PI allocations. Ever. (Well, until policy changes.) The result is now that the established market price for an IP address in the RIPE service region is $signup_fee + $first_period / /22, or 1024 addresses. That's roughly ~2.3 EUR / IPv4 address now in Q3, soon Q4. Will go up Q1 next year. (Adjust for my misunderstanding on what the minimum cost is here) This equates to roughly 35M EUR now heading RIPE's way. The question is: Is this a good thing? This will go faster than many anticipated with the current policy. The reason it will go fast is simply along the lines of the following example: Company X wants IPv4; their ordinary LIR (mothership) now simply applies for new-LIR in Company X name, gets a valid minimum alloc, and then just transfers this back to the mothership and new-LIR is retired ASAP. Adjust for shell-companies, etc, and the direct exchange of Money vs IPv4 addresses between RIPE NCC and the "market" has been fast. The only thing I'm not sure on here, which basically only affects the per-IPv4 price, is what the minimum cost of signing-up and then retiring a new LIR is. Should it *not* be a good thing to transfer 35M EUR to the RIPE NCC in max ~1 year time, we could just allow PI again and just be done with this whole thing. Best, Martin From tore.anderson at redpill-linpro.com Fri Sep 14 13:21:49 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 14 Sep 2012 13:21:49 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: <1347620248.4301.70.camel@galileo.millnert.se> References: <1347620248.4301.70.camel@galileo.millnert.se> Message-ID: <5053134D.7070708@redpill-linpro.com> * Martin Millnert > I'm looking at > https://www.ripe.net/lir-services/resource-management/tools-for-lirs/reponse-time-ipv4 and jump to the conclusion that we're now in final /8 policy land, and IPRAs are out drinking. > > Whether this conclusion is indeed correct is irrelevant, we at close of > business yesterday had 830k remaining addresses above final /8,/13. The IPRAs are most definitively at work today. At the time of writing, only the following prefixes are, as far as I can tell, still available: 91.250.64.0/18 91.250.128.0/17 91.251.0.0/16 176.126.128.0/17 128.0.0.0/16 192.54.244.0/24 192.91.200.0/24 192.133.103.0/24 192.135.185.0/24 192.144.75.0/24 In addition, there are 2368 free addresses in 38 prefixes longer than /24. So unless my math is wrong, there are now only 216640 addresses to go. ~220 tickets open ... I wouldn't bother getting in line at this point, that's for sure. :-) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From richih.mailinglist at gmail.com Fri Sep 14 14:10:32 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 14 Sep 2012 14:10:32 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: <5053134D.7070708@redpill-linpro.com> References: <1347620248.4301.70.camel@galileo.millnert.se> <5053134D.7070708@redpill-linpro.com> Message-ID: On Fri, Sep 14, 2012 at 1:21 PM, Tore Anderson wrote: > The IPRAs are most definitively at work today. At the time of writing, > only the following prefixes are, as far as I can tell, still available: Are you trawling the RIPE db or how did you arrive at that conclusion? We (#networker) would really like to know. -- Richard From carlosm3011 at gmail.com Fri Sep 14 14:34:45 2012 From: carlosm3011 at gmail.com (Carlos Martinez) Date: Fri, 14 Sep 2012 09:34:45 -0300 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: References: <1347620248.4301.70.camel@galileo.millnert.se> <5053134D.7070708@redpill-linpro.com> Message-ID: Extended stats file ? Sent from a mobile device On Sep 14, 2012, at 9:10 AM, Richard Hartmann wrote: > On Fri, Sep 14, 2012 at 1:21 PM, Tore Anderson > wrote: > >> The IPRAs are most definitively at work today. At the time of writing, >> only the following prefixes are, as far as I can tell, still available: > > Are you trawling the RIPE db or how did you arrive at that conclusion? > > We (#networker) would really like to know. > > > -- > Richard > From tore.anderson at redpill-linpro.com Fri Sep 14 15:56:47 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 14 Sep 2012 15:56:47 +0200 (CEST) Subject: [address-policy-wg] Now that final /8 policy may be in action ... Message-ID: The delegated-ripencc-extended-latest shows which blocks were free at the start of the day, then it's just a matter of some whois queries to figure out the rest. Right now it seems 128.0.107.0-128.0.111.255 are still free, plus those five /24s out of 192/8 I listed earlier. And maybe those /25+es (didn't check as I'm on the road at the moment). So it's pretty much all gone now. Tore Richard Hartmann : On Fri, Sep 14, 2012 at 1:21 PM, Tore Anderson wrote: > The IPRAs are most definitively at work today. At the time of writing, > only the following prefixes are, as far as I can tell, still available: Are you trawling the RIPE db or how did you arrive at that conclusion? We (#networker) would really like to know. -- Richard From millnert at gmail.com Fri Sep 14 16:07:31 2012 From: millnert at gmail.com (Martin Millnert) Date: Fri, 14 Sep 2012 16:07:31 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: References: Message-ID: <1347631651.4301.74.camel@galileo.millnert.se> On Fri, 2012-09-14 at 15:56 +0200, Tore Anderson wrote: > The delegated-ripencc-extended-latest shows which blocks were free at the start of the day, then it's just a matter of some whois queries to figure out the rest. > > Right now it seems 128.0.107.0-128.0.111.255 are still free, plus those five /24s out of 192/8 I listed earlier. And maybe those /25+es (didn't check as I'm on the road at the moment). So it's pretty much all gone now. > > Tore Right, as per the announcements [1][2] as well, we're officially in final /8 land now, and IPRAs ran the "available pool" down to the ground. So, somewhere between 35-60M EUR locked up for the RIPE NCC now, from one-shot-LIRs, with current policy. Does the RIPE NCC need all this money or will that complicate things, especially w.r.t IPv4 as an asset issues? Or does it matter what we do? IPv4 just became an asset in this land regardless. :-) Best, Martin [1] http://www.ripe.net/ripe/mail/archives/ncc-announce/2012-September/000615.html [2] https://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8 From richih.mailinglist at gmail.com Fri Sep 14 16:10:45 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 14 Sep 2012 16:10:45 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: References: Message-ID: RIPE announced /8 and I got pi-ipv4 rejected, so... Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamed at skydsl.ir Fri Sep 14 16:20:52 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 18:50:52 +0430 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: <1347632397.4301.77.camel@galileo.millnert.se> References: <1347631651.4301.74.camel@galileo.millnert.se> <1347632397.4301.77.camel@galileo.millnert.se> Message-ID: It?s a shame, a company with fraudulent methods receive 1 million IP address for next three months but my company after giving all requested statics will receive /22 subnet instead of at least /14 subnet!!! On Fri, Sep 14, 2012 at 6:49 PM, Martin Millnert wrote: > Hi Hamed, > > Yes, it's a lottery! > > Sorry that you didn't win. > > I didn't either, tried to get a PI out. :) But didn't get it. > > Best, > Martin > > On Fri, 2012-09-14 at 18:47 +0430, Hamed Shafaghi wrote: > > It?s a shame, a company with fraudulent methods receive 1 million IP > > address for next three months but my company after giving all > > requested statics will receive /22 subnet instead of at least /14 > > subnet!!! > > > > > > > > On Fri, Sep 14, 2012 at 6:37 PM, Martin Millnert > > wrote: > > On Fri, 2012-09-14 at 15:56 +0200, Tore Anderson wrote: > > > The delegated-ripencc-extended-latest shows which blocks > > were free at the start of the day, then it's just a matter of > > some whois queries to figure out the rest. > > > > > > Right now it seems 128.0.107.0-128.0.111.255 are still free, > > plus those five /24s out of 192/8 I listed earlier. And maybe > > those /25+es (didn't check as I'm on the road at the moment). > > So it's pretty much all gone now. > > > > > > Tore > > > > > > Right, as per the announcements [1][2] as well, we're > > officially in > > final /8 land now, and IPRAs ran the "available pool" down to > > the > > ground. > > > > So, somewhere between 35-60M EUR locked up for the RIPE NCC > > now, from > > one-shot-LIRs, with current policy. Does the RIPE NCC need all > > this > > money or will that complicate things, especially w.r.t IPv4 as > > an asset > > issues? Or does it matter what we do? > > > > IPv4 just became an asset in this land regardless. :-) > > > > Best, > > Martin > > > > [1] > > > http://www.ripe.net/ripe/mail/archives/ncc-announce/2012-September/000615.html > > [2] > > > https://www.ripe.net/internet-coordination/news/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8 > > > > > > > > > > > > -- > > I Hamed Shafaghi I > > I Managing Director I > > > > I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I > > > -- 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 hamed at skydsl.ir Fri Sep 14 16:20:00 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 18:50:00 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <504E08CE.1040901@ripe.net> References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> Message-ID: It?s a shame, a company with fraudulent methods receive 1 million IP address for next three months but my company after giving all requested statics will receive /22 subnet instead of at least /14 subnet!!! On Mon, Sep 10, 2012 at 8:05 PM, Andrea Cima wrote: > > Dear all, > > Regarding the comments on allocations in the run-up to reaching the last > /8, we would like to assure you that all requests are met with the highest > level of care and due diligence. We do not make public the details of > specific requests or the documentation provided by our members, but we are > happy to explain the procedures used when evaluating these requests. > > All allocations and assignments are evaluated in accordance with RIPE > Policy and full documentation is required before a request is approved. The > relevant policies are listed in ripe-556, "Due Diligence for the Quality of > the RIPE NCC Registration Data": > https://www.ripe.net/ripe/**docs/ripe-556 > > By default, all large Internet resource requests (/15 or larger for PA > IPv4, /18 or larger for PI IPv4 and /28 or larger for IPv6) are evaluated > by: > - Two IP Resource Analysts (IPRAs) > - The Registration Services Manager > - The Policy Development Officer > - At least two Senior Managers > > In Phase 1 of reaching the last /8, every request for IPv4 address space > is evaluated by two IPRAs, regardless of the size of the request. > > We would also like to note that requests for IPv4 address space are > handled in strict order of receipt by the next available IPRA. > > Further information on the procedures followed by the RIPE NCC to ensure > correct and consistent evaluations of resource requests is available at: > http://www.ripe.net/internet-**coordination/ipv4-exhaustion/** > last-8-phases > http://ripe64.ripe.net/**presentations/168-NCC-**Services-final.pdf > http://ripe63.ripe.net/**presentations/137-end-game.pdf > > If you have any questions on the RIPE NCC's procedures in the run-up to > reaching the last /8, please feel free to contact me. > > Best regards, > Andrea Cima > Registration Services > RIPE NCC > > > -- 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 gert at space.net Fri Sep 14 16:32:10 2012 From: gert at space.net (Gert Doering) Date: Fri, 14 Sep 2012 16:32:10 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> Message-ID: <20120914143210.GE13776@Space.Net> Hi, On Fri, Sep 14, 2012 at 06:50:00PM +0430, Hamed Shafaghi wrote: > It?s a shame, a company with fraudulent methods receive 1 million IP > address for next three months but my company after giving all requested > statics will receive /22 subnet instead of at least /14 subnet!!! While I can understand the frustration of everybody who has not received the amount of IPv4 addresses they have requested or hoped for, please do not vent your steam on the APWG list. We have told everybody that this was coming, and IPv6 was available from the RIPE NCC since August 1998. So just accept the fact that IPv4 is over, and move on. Nothing to see here. (The train wrecks will be in Geoff's presentation) 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 hamed at skydsl.ir Fri Sep 14 16:39:06 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 19:09:06 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <20120914143210.GE13776@Space.Net> References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi Gert, It seems you want to force me to accept receive a 1 million IP address for next three months is fair?? Also please be informed that IPv6 is not routed in IRAN at least for 1 year. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at go6.si Fri Sep 14 16:58:05 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 14 Sep 2012 16:58:05 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: References: <1347631651.4301.74.camel@galileo.millnert.se> <1347632397.4301.77.camel@galileo.millnert.se> Message-ID: <505345FD.407@go6.si> On 9/14/12 4:20 PM, Hamed Shafaghi wrote: > It?s a shame, a company with fraudulent methods receive 1 million IP > address for next three months but my company after giving all requested > statics will receive /22 subnet instead of at least /14 subnet!!! probably a simple matter of where you were in the queue. nothing to do with any conspiracy theory :) jan From maildanrl at gmail.com Fri Sep 14 17:13:40 2012 From: maildanrl at gmail.com (Dan Luedtke) Date: Fri, 14 Sep 2012 17:13:40 +0200 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: <20120906125000.GD13776@Space.Net> References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> <20120906125000.GD13776@Space.Net> Message-ID: Hi everyone, On Thu, Sep 6, 2012 at 2:50 PM, Gert Doering wrote: >> I support the proposal. > > "as is", or "with anonymizing rejected applications"? I think I can live with both. Just count me in. Regards Dan From sander at steffann.nl Fri Sep 14 17:16:14 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 14 Sep 2012 17:16:14 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi Hamed, > It seems you want to force me to accept receive a 1 million IP address for next three months is fair?? It can be, depending on *many* factors. I know that the RIPE NCC IPRA's have been very thorough when checking documentation for requests, so if they approved a request it must have had good documentation. If you really have good grounds to base your accusation of fraud on then you can contact the RIPE NCC and ask them to look at it. This has been documented in RIPE-423 (http://www.ripe.net/ripe/docs/ripe-423) > Also please be informed that IPv6 is not routed in IRAN at least for 1 year. That is a problem that Iran has to fix. There is no more IPv4 available to support further growth. I have seen the same in other countries in the Middle East. In most cases where are ways to tunnel IPv6 traffic over the existing IPv4 infrastructure. It is far from optimal, but it does give you some options. A well-known one is tunnelbroker.net by Hurricane Electric. They also support announcing your own address space with BGP over the tunnel. I know the shortage of IPv4 addresses is annoying, but the whole community has seen this coming for years. Network operators should have prepared for this moment long ago, but I understand the frustration if your national telco operator has not done its job and you are still required to use their services... - Sander From sander at steffann.nl Fri Sep 14 17:17:32 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 14 Sep 2012 17:17:32 +0200 Subject: [address-policy-wg] Now that final /8 policy may be in action ... In-Reply-To: <505345FD.407@go6.si> References: <1347631651.4301.74.camel@galileo.millnert.se> <1347632397.4301.77.camel@galileo.millnert.se> <505345FD.407@go6.si> Message-ID: <975D38F0-84E9-433D-BB07-717573B11A2F@steffann.nl> >> It?s a shame, a company with fraudulent methods receive 1 million IP >> address for next three months but my company after giving all requested >> statics will receive /22 subnet instead of at least /14 subnet!!! > > probably a simple matter of where you were in the queue. nothing to do with any conspiracy theory :) And with a queue of over 200 requests I think most people in that queue have been disappointed... Sander From hamed at skydsl.ir Fri Sep 14 17:44:19 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 20:14:19 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi Sander, Thanks for your attention and your guides About paragraph 1 I will follow your instructions. And about paragraph 2 I must say using any type of tunnel (really any type) in IRAN is illegal and have injunction for 6 month to 1 year imprisonment. There are many problems about implementing IPv6 in IRAN that I do want to write about them here. Obviously I do not have any hope of launching IPv6 in IRAN in next 12 months. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Sep 14 18:14:13 2012 From: sander at steffann.nl (Sander Steffann) Date: Fri, 14 Sep 2012 18:14:13 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi Hamed, > Thanks for your attention and your guides > > About paragraph 1 I will follow your instructions. > > And about paragraph 2 I must say using any type of tunnel (really any type) in IRAN is illegal and have injunction for 6 month to 1 year imprisonment. Ouch! > There are many problems about implementing IPv6 in IRAN that I do want to write about them here. > Obviously I do not have any hope of launching IPv6 in IRAN in next 12 months. Then running the network will probably have to focus on work-arounds until IPv6 arrives in Iran. I hope that the news today makes things move a bit faster in your country. - Sander From hlk at kramse.org Fri Sep 14 18:16:18 2012 From: hlk at kramse.org (=?iso-8859-1?Q?Henrik_Lund_Kramsh=F8j?=) Date: Fri, 14 Sep 2012 18:16:18 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: On 14/09/2012, at 16.39, Hamed Shafaghi wrote: > Hi Gert, Dear Hamed > > It seems you want to force me to accept receive a 1 million IP address for next three months is fair?? Please understand this in the most constructive way. IPv4 pool depletion has not happened overnight. I have had various request tickets sent and approved throughout the last years, for myself and customers. If you today are left without addresses it is sad, but it can only be because you did NOT see this coming. Who is to blame? You blame RIPE? Whereas I think we can agree that RIPE has been very open as to their methods, processing and so on. > > Also please be informed that IPv6 is not routed in IRAN at least for 1 year. If the country of Iran did NOT expect IPv6 to come, it is not our fault. It is probably is not your fault either. Do your best to persuade the people who can help to accelerate adoption of IPv6! You are always welcome to create tunnels for IPv6 across IPv4, I might even encourage you to do so! but blaming RIPE and accusing them of using "fraudulent methods", just STOP IT! If you want solutions, be constructive, and I am very sure lots of people will do their best to help you :-) Best regards Henrik -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 http://solidonetworks.com/ Network Security is a business enabler From hamed at skydsl.ir Fri Sep 14 18:43:06 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 21:13:06 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi Henrik, Please be calm down, I think you are confused; I do not blaming RIPE NCC at all. We talk about another company NOT RIPE NCC. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Sep 14 19:05:43 2012 From: gert at space.net (Gert Doering) Date: Fri, 14 Sep 2012 19:05:43 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: <20120914170543.GF13776@Space.Net> Hi, On Fri, Sep 14, 2012 at 07:09:06PM +0430, Hamed Shafaghi wrote: > It seems you want to force me to accept receive a 1 million IP address for > next three months is fair?? IPv4 run-out is not fair, for nobody. Someone was lucky in getting the last large block, many people came a few minutes too late. > Also please be informed that IPv6 is not routed in IRAN at least for 1 year. Then route it. If needed, there are lots of people that are willing to provide help in setting up IPv6 - be it helping with router config, providing IPv6 tunnels if necessary, etc. 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 hamed at skydsl.ir Fri Sep 14 19:17:39 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 21:47:39 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: <20120914170543.GF13776@Space.Net> References: <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> <20120914170543.GF13776@Space.Net> Message-ID: Hi, Please read my text carefully. Nationwide Fiber optic infrastructure and internet gateway operated by government and they do not have a short-term plan for IPv6 at this moment also using any type of tunnel in Iran is illegal and if we use this it is push me to jail for at least 6 months. Again please read my text carefully -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamed at skydsl.ir Fri Sep 14 19:46:34 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 22:16:34 +0430 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <5.1.1.6.2.20120420133256.01f4e5f8@efes.iucc.ac.il> <855077AC3D7A7147A7570370CA01ECD212B679@SUEX10-mbx-10.ad.syr.edu> <855077AC3D7A7147A7570370CA01ECD212C066@SUEX10-mbx-10.ad.syr.edu> <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> Message-ID: Hi, Now I?m seeking for at least /14 IPv4 space for inter-RIR transfer, if anybody know company that have This size (Or not less than /15) please inform me, this is critical request. -- 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 hamed at skydsl.ir Fri Sep 14 19:47:16 2012 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Fri, 14 Sep 2012 22:17:16 +0430 Subject: [address-policy-wg] 2012-05 New Policy Proposal (Transparency in Address Block Transfers) In-Reply-To: References: <4fcca92e.4d5e0e0a.2ba4.ffffaacaSMTPIN_ADDED@mx.google.com> <855077AC3D7A7147A7570370CA01ECD218277F@SUEX10-mbx-10.ad.syr.edu> <50472392.303@CC.UniVie.ac.at> <50472660.5050709@redpill-linpro.com> <855077AC3D7A7147A7570370CA01ECD220D6C0@SUEX10-mbx-10.ad.syr.edu> <20120906125000.GD13776@Space.Net> Message-ID: Hi, Now I?m seeking for at least /14 IPv4 space for inter-RIR transfer, if anybody know company that have This size (Or not less than /15) please inform me, this is critical request. -- 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 gert at space.net Fri Sep 14 19:50:04 2012 From: gert at space.net (Gert Doering) Date: Fri, 14 Sep 2012 19:50:04 +0200 Subject: [address-policy-wg] Revert "Run Out Fairly" after IPv4 depletion In-Reply-To: References: <20120423110738.GI84425@Space.Net> <855077AC3D7A7147A7570370CA01ECD21417D5@SUEX10-mbx-10.ad.syr.edu> <20120424131514.GB84425@Space.Net> <5.1.1.6.2.20120910091130.05384d78@efes.iucc.ac.il> <504E08CE.1040901@ripe.net> <20120914143210.GE13776@Space.Net> <20120914170543.GF13776@Space.Net> Message-ID: <20120914175004.GG13776@Space.Net> Hi, On Fri, Sep 14, 2012 at 09:47:39PM +0430, Hamed Shafaghi wrote: > Please read my text carefully. > > > Nationwide Fiber optic infrastructure and internet gateway operated by > government and they do not have a short-term plan for IPv6 at this moment > also using any type of tunnel in Iran is illegal and if we use this it is > push me to jail for at least 6 months. Sorry, I read that text only after I answered one of your earlier e-mails. This is nothing APWG can help with, though, as much as we want to. Sorry. 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 ripe.address-policy-wg at ml.karotte.org Sat Sep 15 16:57:48 2012 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Sat, 15 Sep 2012 16:57:48 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <20120915145748.GA18320@danton.fire-world.de> * Randy Bush [2012-09-10 16:00]: > i can not speak to the intent in the ripe region. but the principal > intent of the final /8 policy in the apnic region was so that *new* > entrants could get one small piece of the pie. > > in the years when we have a mixed 6/4 internet, folk will need a wee bit > of v4 space for things such as nat64 and other ways face the dual stack > world. > > pissing it away in greed and/or arrogance is not responsible to our > children. I agree with Randy and oppose this proposal. We should not use the last /8 for PI space but for LIRs who need at least a bit of v4 space to get going. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From dioakimoglou at globoplc.com Sun Sep 16 09:24:54 2012 From: dioakimoglou at globoplc.com (ioakimoglou) Date: Sun, 16 Sep 2012 10:24:54 +0300 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120915145748.GA18320@danton.fire-world.de> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> Message-ID: <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> Hello everyone, This is my first post in any of the RIPE mailing lists, I'm not even sure if I'm qualified or even "allowed". So feel free to put me in place, if needed :) I find Randy's post about the last /8 going to new entrants to be the most convincing one. Giving it away to us (LIRS who are already in possession of at least a /21) should be secondary to giving it to newcomers who really need it in order to get started. I don't mean that's the only group of companies/orgs that should be considered, but they DO need this the most. It's one thing to be tight with the resources you already have, and another to not have them at all. And anyway, how much would life change for an ISP, for example, just cause they got an extra /22? How much time would it really buy? Is that time as valuable as the ability for the new guys to also get SOME ipv4 connectivity? Sorry if I'm out of place, again, I just thought I should try this. Dimitris Ioakimoglou Skype: dioakimoglou Linkedin: http://gr.linkedin.com/pub/dimitris-ioakimoglou/43/510/12 dioakimoglou at globoplc.com | globoplc.com Experience GO!Enterprise Server on your mobile/tablet. Download a demo. -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sebastian Wiesinger Sent: Saturday, September 15, 2012 5:58 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) * Randy Bush [2012-09-10 16:00]: > i can not speak to the intent in the ripe region. but the principal > intent of the final /8 policy in the apnic region was so that *new* > entrants could get one small piece of the pie. > > in the years when we have a mixed 6/4 internet, folk will need a wee > bit of v4 space for things such as nat64 and other ways face the dual > stack world. > > pissing it away in greed and/or arrogance is not responsible to our > children. I agree with Randy and oppose this proposal. We should not use the last /8 for PI space but for LIRs who need at least a bit of v4 space to get going. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ________________________________ This e-mail may contain information that is PRIVILEGED and/or CONFIDENTIAL. This e-mail is intended solely for the individual or entity to whom it is addressed. If you are not, or have reason to believe you are not the intended recipient of this e-mail please contact us by reply e-mail as soon as possible and delete the message (including attachment(s)) from your computer system(s) without disclosing it. Any unauthorized review, use, copying, disclosure or distribution of this e-mail (including attachment(s)) is prohibited. The content of this e-mail may contain personal views of its author and does therefore not necessarily reflect the views or policies of Globo (Globo Technologies S.A., Globo Mobile S.A., Profitel S.A, Globo Plc, Globo International LLC ).Globo hereby disclaims any and all liabilities which may arise in relation to any of its electronic communication. No obligation is entered into by virtue of this e-mail, unless confirmed in writing and duly signed by an authorized representative of Globo. All outgoing and incoming emails are scanned for malicious code and all malicious code infections are being automatically reported to the appropriate IS Administrators. From bgp2 at linuxadmin.org Sun Sep 16 10:56:47 2012 From: bgp2 at linuxadmin.org (Greg) Date: Sun, 16 Sep 2012 04:56:47 -0400 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> References: "<3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan>" <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> Message-ID: <9081dd0c974b5bae183b9c2e6a347ced@utraffic.com> I support this proposal. End-users should be given the choice to get one PI /24 space when needed. We shouldn't limit new start-ups or existing companies that need ipv4 space for their business, for example, multi-homing. By limiting PI allocations to end-users from the last /8, we do not solve the problem of running out of IPv4 space much anyway... IPv6 is the future only... Sincerely, Greg LinuxAdmin From Fernando.Garcia at tecnocom.es Sun Sep 16 13:05:06 2012 From: Fernando.Garcia at tecnocom.es (=?iso-8859-1?Q?Garc=EDa_Fern=E1ndez=2C_Fernando?=) Date: Sun, 16 Sep 2012 13:05:06 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120915145748.GA18320@danton.fire-world.de> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> Message-ID: <03CE1BC9-B5C0-442E-8908-AF2491EFC8B8@tecnocom.es> +1 I'm also against this proposal. Regards. Fernando Garcia Fernandez Arquitecto de Redes y Sistemas Integraci?n de Sistemas y Tecnolog?a Josefa Valc?rcel 26, Edificio Merrimark III Madrid 28027 Tel. Fijo: (+34) 901900900 ext 40383 Tel. M?vil / Fax: (+34) 649428591 (20383) email: fernando.garcia at tecnocom.es http://www.tecnocom.es El 15/09/2012, a las 16:57, Sebastian Wiesinger escribi?: > * Randy Bush [2012-09-10 16:00]: >> i can not speak to the intent in the ripe region. but the principal >> intent of the final /8 policy in the apnic region was so that *new* >> entrants could get one small piece of the pie. >> >> in the years when we have a mixed 6/4 internet, folk will need a wee bit >> of v4 space for things such as nat64 and other ways face the dual stack >> world. >> >> pissing it away in greed and/or arrogance is not responsible to our >> children. > > I agree with Randy and oppose this proposal. We should not use the > last /8 for PI space but for LIRs who need at least a bit of v4 space > to get going. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. > -- Terry Pratchett, The Fifth Elephant > From jan at go6.si Sun Sep 16 16:52:11 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 16 Sep 2012 16:52:11 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> Message-ID: <5055E79B.1020204@go6.si> On 9/10/12 3:54 PM, Randy Bush wrote: > in the years when we have a mixed 6/4 internet, folk will need a wee bit > of v4 space for things such as nat64 and other ways face the dual stack > world. > > pissing it away in greed and/or arrogance is not responsible to our > children. I was thinking a bit about this and could not decide for long time. I would say to save the last bits of v4 addresses for folx, that will actually connect end/residential users to Internet infrastructure and will be in need of at least some small amount of v4 in order to run nat64 or any other transition mechanism. That's was called PA space in the past. IPv4 PI was never meant for that, but more for enterprises in order to be able to multihome. That luxury times are over and I think that the policy should reflect that. Cheers, Jan From lists-ripe at c4inet.net Sun Sep 16 17:12:24 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sun, 16 Sep 2012 16:12:24 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055E79B.1020204@go6.si> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <5055E79B.1020204@go6.si> Message-ID: <20120916151224.GA31709@cilantro.c4inet.net> On Sun, Sep 16, 2012 at 04:52:11PM +0200, Jan Zorz @ go6.si wrote: >IPv4 PI was never meant for that, but more for enterprises in order >to be able to multihome. That luxury times are over and I think that >the policy should reflect that. that would be the LIR-centric view. However, I understand the intention of the LIR system for the LIRs to be resource-management organisations rather than a club with exclusive access to resources. Therefore an end-user is no less "entitled" to IP resources than a LIR and 2012-04 in current form is arbitrarily discriminationg. rgds, Sascha Luck From lists-ripe at c4inet.net Sun Sep 16 17:18:28 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sun, 16 Sep 2012 16:18:28 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> Message-ID: <20120916151828.GB31709@cilantro.c4inet.net> On Sun, Sep 16, 2012 at 10:24:54AM +0300, ioakimoglou wrote: >Hello everyone, This is my first post in any of the RIPE mailing lists, >I'm not even sure if I'm qualified or even "allowed". So feel free to >put me in place, if needed :) Anyone who uses internet resources (in the RIPE region) is the constituency of the apwg mailing list, so don't worry about being "qualified" :) >I find Randy's post about the last /8 going to new entrants to be the >most convincing one. Giving it away to us (LIRS who are already in >possession of at least a /21) should be secondary to giving it to >newcomers who really need it in order to get started. I don't mean >that's the only group of companies/orgs that should be considered, but >they DO need this the most. This is out-of-scope for this particular proposal though as it doesn't address whether ipv4 resources should be restricted to newcomers only. rgds, Sascha Luck From president at ukraine.su Sun Sep 16 17:54:49 2012 From: president at ukraine.su (Max Tulyev) Date: Sun, 16 Sep 2012 18:54:49 +0300 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> Message-ID: <5055F649.5040503@ukraine.su> Hello everyone, I support this. Also I can say the PI should be distributed as well. There are lot of companies, educational entities, small networks can't become a LIR as for money and/or formalities (bueracracy) issues. PI can be limited to /24. It is quite enough for small and even medium size organisation to maintain multihomed IPv4 connection. 16.09.12 10:24, ioakimoglou ???????(??): > Hello everyone, > This is my first post in any of the RIPE mailing lists, I'm not even sure if > I'm qualified or even "allowed". > So feel free to put me in place, if needed :) > > I find Randy's post about the last /8 going to new entrants to be the most > convincing one. > Giving it away to us (LIRS who are already in possession of at least a /21) > should be secondary to giving it to newcomers who really need it in order to > get started. > I don't mean that's the only group of companies/orgs that should be > considered, but they DO need this the most. > > It's one thing to be tight with the resources you already have, and another > to not have them at all. > > And anyway, how much would life change for an ISP, for example, just cause > they got an extra /22? How much time would it really buy? > Is that time as valuable as the ability for the new guys to also get SOME > ipv4 connectivity? > > Sorry if I'm out of place, again, I just thought I should try this. > > > Dimitris Ioakimoglou > Skype: dioakimoglou > Linkedin: http://gr.linkedin.com/pub/dimitris-ioakimoglou/43/510/12 > dioakimoglou at globoplc.com | globoplc.com > > > > Experience GO!Enterprise Server on your mobile/tablet. Download a demo. > > -----Original Message----- > From: address-policy-wg-bounces at ripe.net > [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sebastian Wiesinger > Sent: Saturday, September 15, 2012 5:58 PM > To: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] [policy-announce] 2012-04 New Draft > Document Published (PI Assignments from the last /8) > > * Randy Bush [2012-09-10 16:00]: >> i can not speak to the intent in the ripe region. but the principal >> intent of the final /8 policy in the apnic region was so that *new* >> entrants could get one small piece of the pie. >> >> in the years when we have a mixed 6/4 internet, folk will need a wee >> bit of v4 space for things such as nat64 and other ways face the dual >> stack world. >> >> pissing it away in greed and/or arrogance is not responsible to our >> children. > > I agree with Randy and oppose this proposal. We should not use the last /8 > for PI space but for LIRs who need at least a bit of v4 space to get going. > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant > > > > ________________________________ > > This e-mail may contain information that is PRIVILEGED and/or CONFIDENTIAL. This e-mail is intended solely for the individual or entity to whom it is addressed. If you are not, or have reason to believe you are not the intended recipient of this e-mail please contact us by reply e-mail as soon as possible and delete the message (including attachment(s)) from your computer system(s) without disclosing it. Any unauthorized review, use, copying, disclosure or distribution of this e-mail (including attachment(s)) is prohibited. The content of this e-mail may contain personal views of its author and does therefore not necessarily reflect the views or policies of Globo (Globo Technologies S.A., Globo Mobile S.A., Profitel S.A, Globo Plc, Globo International LLC ).Globo hereby disclaims any and all liabilities which may arise in relation to any of its electronic communication. No obligation is entered into by virtue of this e-mail, unless confirmed in writing and duly signed by an authoriz ed representative of Globo. All outgoing and incoming emails are scanned for malicious code and all malicious code infections are being automatically reported to the appropriate IS Administrators. > From jan at go6.si Sun Sep 16 18:33:54 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 16 Sep 2012 18:33:54 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120916151224.GA31709@cilantro.c4inet.net> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <5055E79B.1020204@go6.si> <20120916151224.GA31709@cilantro.c4inet.net> Message-ID: <5055FF72.3040903@go6.si> On 9/16/12 5:12 PM, Sascha Luck wrote: > On Sun, Sep 16, 2012 at 04:52:11PM +0200, Jan Zorz @ go6.si wrote: >> IPv4 PI was never meant for that, but more for enterprises in order to >> be able to multihome. That luxury times are over and I think that the >> policy should reflect that. > > that would be the LIR-centric view. However, I understand the intention > of the LIR system for the LIRs to be resource-management organisations > rather than a club with exclusive access to resources. Therefore an > end-user is no less "entitled" to IP resources than a LIR and 2012-04 in > current form is arbitrarily discriminationg. In a way I agree with you, but we need to look at this issue from pragmatic point of view. I don't see much of a benefit for the Internet community and infrastructure if a company with 5 employees and two internet servers gets the whole /24 just because they need multihoming and are able to pay few EUR per year for that. As I already mentioned, v4 resources are over and also luxury times are over. If you are new on the campus, do multihoming on IPv6, get IPv4 assignment from one (or both) of your upstreams and get over with it. I know you will probably not be able to run BGP for IPv4 resources - but that's how it is now, there's a new sheriff in town :) Cheers, Jan From jan at go6.si Sun Sep 16 18:34:49 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 16 Sep 2012 18:34:49 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055F649.5040503@ukraine.su> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> Message-ID: <5055FFA9.201@go6.si> On 9/16/12 5:54 PM, Max Tulyev wrote: > Hello everyone, > > I support this. > > Also I can say the PI should be distributed as well. There are lot of > companies, educational entities, small networks can't become a LIR as > for money and/or formalities (bueracracy) issues. ...and all of them needs to be multihomed? Cheers, Jan From corebug at corebug.net Sun Sep 16 19:14:21 2012 From: corebug at corebug.net (=?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KLRg9GA0L7QstC10YY=?=) Date: Sun, 16 Sep 2012 20:14:21 +0300 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055FFA9.201@go6.si> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> Message-ID: 2012/9/16 Jan Zorz @ go6.si : > On 9/16/12 5:54 PM, Max Tulyev wrote: >> >> Hello everyone, >> >> I support this. >> >> Also I can say the PI should be distributed as well. There are lot of >> companies, educational entities, small networks can't become a LIR as >> for money and/or formalities (bueracracy) issues. > > > ...and all of them needs to be multihomed? > > Cheers, Jan > > At least, some percent of those needs to. -- ~~~ WBR, Vitaliy Turovets NOC Lead @TV-Net ISP NOC Lead @Service Outsourcing company +38(093)265-70-55 VITU-RIPE X-NCC-RegID: ua.tv From tore.anderson at redpill-linpro.com Sun Sep 16 19:41:50 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Sun, 16 Sep 2012 19:41:50 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055FF72.3040903@go6.si> References: <20120910121712.D7AEAED4580@klant.eznet.nl> <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <5055E79B.1020204@go6.si> <20120916151224.GA31709@cilantro.c4inet.net> <5055FF72.3040903@go6.si> Message-ID: <50560F5E.5010808@redpill-linpro.com> * Jan Zorz @ go6.si > I don't see much of a benefit for the Internet community and > infrastructure if a company with 5 employees and two internet > servers gets the whole /24 just because they need multihoming and are > able to pay few EUR per year for that. Currently they'll have to get a /22 instead. How is that any better? -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From gert at space.net Sun Sep 16 20:09:58 2012 From: gert at space.net (Gert Doering) Date: Sun, 16 Sep 2012 20:09:58 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055F649.5040503@ukraine.su> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> Message-ID: <20120916180958.GF13776@Space.Net> Hi, On Sun, Sep 16, 2012 at 06:54:49PM +0300, Max Tulyev wrote: > Hello everyone, > > I support this. Support *what*? The posting you've quoted argues for a completely different change ("do not give last-/22 to LIRs that already have space"), which is out of scope for the 2012-04 discussion. So your comment is somewhat unclear regarding support or non-support for the proposal at hand. 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 nick at inex.ie Sun Sep 16 20:19:08 2012 From: nick at inex.ie (Nick Hilliard) Date: Sun, 16 Sep 2012 19:19:08 +0100 Subject: [address-policy-wg] Temporary Internet Assignments policy Message-ID: <5056181C.7050607@inex.ie> There's a thread on nanog-l at the moment about temporary internet assignments: > http://mailman.nanog.org/pipermail/nanog/2012-September/051655.html I had already booked a slot in the AP-WG under AOB to talk about this because the policy is broken and needs fixing. Specifically, the timescales specified in the policy allow the assignment to be made one week before use: the consistent feedback is that this isn't enough time for large conference organisers to get things organised in time. The problems we're trying to address are: - enough time for debogonisation - enough time for pre-configuring equipment prior to shipment (which can be weeks in advance) - not knowing well in advance what address ranges you're going to get causes massive headaches, which is exactly what you don't need coming up to a frenzied configuration - conference attendees often arrive several days earlier than the conference formally starts, and they expect teh interwebs to work There are a couple of options for dealing with this: 1. specify new time limits (e.g. receive one month in advance, hand back one week after) 2. don't specify time limits but allow the IPRAs to have discretion on what seems sensible to them 3. keep the current time limits but ask the RIPE NCC whether it would be possible to implement a booking system. I.e. your assignment would only be active during the requested time period, but you would know well in advance what the options were. If anyone has opinions on which of these they prefer (or any other suggestions on how to deal with the issue), can you either post here or let me know off-list and I'll summarise at RIPE65 in advance of posting a policy amendment for ripe-526 shortly after the meeting? Nick From randy at psg.com Mon Sep 17 05:27:27 2012 From: randy at psg.com (Randy Bush) Date: Mon, 17 Sep 2012 12:27:27 +0900 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5055F649.5040503@ukraine.su> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> Message-ID: gedanken experiment o cut last/8 allocations to lirs back to /24 o give end sites /29s from a specific block. lets them nat. randy From tore.anderson at redpill-linpro.com Mon Sep 17 08:29:21 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 17 Sep 2012 08:29:21 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5056181C.7050607@inex.ie> References: <5056181C.7050607@inex.ie> Message-ID: <5056C341.7000903@redpill-linpro.com> * Nick Hilliard > 2. don't specify time limits but allow the IPRAs to have discretion > on what seems sensible to them +1. KISS and so on. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From richih.mailinglist at gmail.com Mon Sep 17 08:50:13 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 17 Sep 2012 08:50:13 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5056181C.7050607@inex.ie> References: <5056181C.7050607@inex.ie> Message-ID: IPRAs should have leeway to decide and adapt. Specifying min/max periods would not hurt, though. Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garry at nethinks.com Mon Sep 17 08:40:56 2012 From: garry at nethinks.com (Garry Glendown) Date: Mon, 17 Sep 2012 08:40:56 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> Message-ID: <5056C5F8.2060902@nethinks.com> On 17.09.2012 05:27, Randy Bush wrote: > gedanken experiment > > o cut last/8 allocations to lirs back to /24 Most likely too small to do anything meaningful with ... Anyway, I've been wondering for a while - how many new ISPs (or LIRs, for that matter) have been founded over the last - say - 2 years? Given the technical requirements as far as performance and bandwidths go, and the low end user prices for Internet connectivity, I don't see how there are any feasible business models to start an ISP business nowadays... this poses the question whether saving v4 addresses for new ISPs/LIRs is even relevant ... > o give end sites /29s from a specific block. lets them nat. Apart from uses like VPN transfer networks (for which a /29 should be plenty sufficient in many cases, though possibly too smal in some special situations with many servers), this isn't sufficient for the predominant use, multi-homing. Question is - as others have already stated - whether multi-homing is a valid reason for getting v4 addresses in this phase ... I reckon if the policy should be altered to allow v4PI assignments, should there be a quota between PI and LIR assignments? I've not read up on the amount of reserved space for future uses, but say that's 20%, should there be a 4:1 ratio between PA and PI, eg. 64% PA and 16% PI? Also, should there be some sort of regulation as to what businesses ought to be allowed to receive LIR status? Otherwise, regular end customers with enough money (or enough despair) could chose to become an LIR, wasting more space than they would getting (currently unavailble) PI space, with only one company profiting from /22, while "real" LIRs might not get anything at some point, with dozens or hundreds of end customers not being able to get v4 addresses ... -garry From frettled at gmail.com Mon Sep 17 09:15:28 2012 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 17 Sep 2012 09:15:28 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5056C5F8.2060902@nethinks.com> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5056C5F8.2060902@nethinks.com> Message-ID: On Mon, Sep 17, 2012 at 8:40 AM, Garry Glendown wrote: > > Anyway, I've been wondering for a while - how many new ISPs (or LIRs, for > that matter) have been founded over the last - say - 2 years? Given the > technical requirements as far as performance and bandwidths go, and the low > end user prices for Internet connectivity, I don't see how there are any > feasible business models to start an ISP business nowadays... this poses > the question whether saving v4 addresses for new ISPs/LIRs is even relevant > ... I assume you mean Internet access providers when you write ISP, and not those who provide e.g. hosting services etc. Hosting service companies crop up all the time. I don't have the numbers, but I'm working for a medium-sized outfit in that business, and we've seen new competitors cropping up more often in 2011 and 2012 than was typical for the previous 5-10 years. Fortunately, hosting providers can often make do with a small number of IP addresses, comparatively speaking. Unfortunately, due to Facebook, a LOT of end users want SSL connectivity for their websites (blogs and whatnot). -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at nosignal.org Mon Sep 17 09:08:36 2012 From: andy at nosignal.org (Andy Davidson) Date: Mon, 17 Sep 2012 08:08:36 +0100 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5056181C.7050607@inex.ie> References: <5056181C.7050607@inex.ie> Message-ID: <0FF01B7D-3000-4739-A17B-C066ACBC6E95@nosignal.org> On 16 Sep 2012, at 19:19, Nick Hilliard wrote: > 2. don't specify time limits but allow the IPRAs to have discretion on what seems sensible to them J'aime. From rg at teamix.de Mon Sep 17 08:05:29 2012 From: rg at teamix.de (Rico Gloeckner) Date: Mon, 17 Sep 2012 08:05:29 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120915145748.GA18320@danton.fire-world.de> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> Message-ID: <20120917060529.GA19906@teamix.net> Hi, On Sat, Sep 15, 2012 at 04:57:48PM +0200, Sebastian Wiesinger wrote: > I agree with Randy and oppose this proposal. We should not use the > last /8 for PI space but for LIRs who need at least a bit of v4 space > to get going. There is no distinct difference between LIR and non-LIR except paying two grand a year. Lets assume the simple scenario that someone wants IP Space. Without the proposal you pay 2 grand a year and get a /22, no questions asked. With the Proposal you pay whatever your LIR bills you and get a /24. I assume there will be quite some (non-ISP) Organizations who will choose being LIR over getting a PI because they get more IP Adresses. Without the proposal you force ALL organizations to do so. Now, which scenario will likely run out quicker? Rico MfG/regards, -- Rico Gloeckner teamix GmbH Suedwestpark 35 90449 Nuernberg Amtsgericht Nuernberg, HRB 18320 Geschaeftsfuehrer: Oliver Kuegow, Richard Mueller From millnert at gmail.com Mon Sep 17 11:01:23 2012 From: millnert at gmail.com (Martin Millnert) Date: Mon, 17 Sep 2012 11:01:23 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5056C5F8.2060902@nethinks.com> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5056C5F8.2060902@nethinks.com> Message-ID: <1347872483.4301.123.camel@galileo.millnert.se> On Mon, 2012-09-17 at 08:40 +0200, Garry Glendown wrote: > On 17.09.2012 05:27, Randy Bush wrote: > > gedanken experiment > > > > o cut last/8 allocations to lirs back to /24 > Most likely too small to do anything meaningful with ... > > Anyway, I've been wondering for a while - how many new ISPs (or LIRs, > for that matter) have been founded over the last - say - 2 years? Given > the technical requirements as far as performance and bandwidths go, and > the low end user prices for Internet connectivity, I don't see how there > are any feasible business models to start an ISP business nowadays... > this poses the question whether saving v4 addresses for new ISPs/LIRs is > even relevant ... Any future upstart-ISP *NEED* IPv4 space to do CGN. A small block is sufficient. Not having access to it is tricky w.r.t competition legislation (the holders of IPv4 not selling some to new-comers, thus blocking the market or whatever). This isn't an argument pro or con PIv4-from-last-/8 in itself, unless ISP operations are restricted to companies that are also LIRs, which, well, it isn't. For the record-keepers, I'm pro 2012-04. In my opinion, a real solution to the above problem is not found in the distribution model of an extremely limited amount of space (last /8). And we're going there anyway (to the situation requiring the real solution), I would just like us to get there sooner rather than later so we can stop fumbling for non-solutions. It gets us IPv6 faster, is my theory. And it's of course debatable whether new-LIR cost for /22 contra PI-process for /24. The opportunistic PI-applications are probably quite limited in volume? However, need for address space is somewhat in-elastic, like having gas in your car when driving to work. Many enterprises need it regardless of its form and will easily pay 3.5 EUR/address for one or several /22. FFWD, plz. Best, M From flo at degnet.de Mon Sep 17 11:31:30 2012 From: flo at degnet.de (Florian Fuessl) Date: Mon, 17 Sep 2012 11:31:30 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> Message-ID: <01a401cd94b7$395f8620$ac1e9260$@de> Hi, > Vitaly Turovets wrote Sun, Sep 16, 2012 7:14 PM > 2012/9/16 Jan Zorz @ go6.si : > > On 9/16/12 5:54 PM, Max Tulyev wrote: > >> > >> Hello everyone, > >> > >> I support this. > >> > >> Also I can say the PI should be distributed as well. There are lot > >> of companies, educational entities, small networks can't become > >> a LIR as for money and/or formalities (bueracracy) issues. > > > > ...and all of them needs to be multihomed? > > > > Cheers, Jan > > At least, some percent of those needs to. > > Vitaliy Turovets How about limiting IPv4 PI assignments to a total max of /12 (?) within the remaining /8 pool? Without knowing the exact statistics on IPv4 PI assignments by RIPE I guess this could be a compromise for entities needing IPv4 PI address space within the next time by still preserving enough resources for new members for the coming years. To higher the burden of possible abuse, IPv4 PI assignment requests may be only possible after having routed IPv6 PI address space, already. -Florian -- IT Manager, Dipl.-Ing. Florian Fuessl ----------------------------------------------------------------------- DegNet GmbH GF: Lothar Mayer Tel +49-991-3830566 Westl. Stadtgraben 20 AG Deggendorf HRB 2199 Fax +49-991-3830567 94469 Deggendorf http://www.degnet-gmbh.de mailto>>ff at deg.net<< ----------------------------------------------------------------------- From gert at space.net Mon Sep 17 11:47:11 2012 From: gert at space.net (Gert Doering) Date: Mon, 17 Sep 2012 11:47:11 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <01a401cd94b7$395f8620$ac1e9260$@de> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> <01a401cd94b7$395f8620$ac1e9260$@de> Message-ID: <20120917094711.GK13776@Space.Net> Hi, On Mon, Sep 17, 2012 at 11:31:30AM +0200, Florian Fuessl wrote: > How about limiting IPv4 PI assignments to a total max of /12 (?) within the > remaining /8 pool? This sounds somewhat familiar. "Limit IPv4 PI to all but the last /8" Last /8 reached "Limit IPv4 PI to just a /12 out of the last /8" that /12 empty "Limit IPv4 PI to another /12 out of the last /8" ... I'm not sure if "every time the available pool for X is empty, just grab another slice of the rest and declare it to be 'available for X, but limited!!'" is a reasonable strategy... 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 nick at inex.ie Mon Sep 17 12:25:35 2012 From: nick at inex.ie (Nick Hilliard) Date: Mon, 17 Sep 2012 11:25:35 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <20120917094711.GK13776@Space.Net> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> <01a401cd94b7$395f8620$ac1e9260$@de> <20120917094711.GK13776@Space.Net> Message-ID: <5056FA9F.6030801@inex.ie> On 17/09/2012 10:47, Gert Doering wrote: > ... I'm not sure if "every time the available pool for X is empty, just > grab another slice of the rest and declare it to be 'available for X, but > limited!!'" is a reasonable strategy... +1 To be clear, as proposer of this policy, I'm interested in a long term solution for PI so that we have long term policy clarity for PI assignment in the RIPE service region. I'm not interested in a series of stop-gap measures. Nick From richih.mailinglist at gmail.com Mon Sep 17 13:02:57 2012 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 17 Sep 2012 13:02:57 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <5056FA9F.6030801@inex.ie> References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> <01a401cd94b7$395f8620$ac1e9260$@de> <20120917094711.GK13776@Space.Net> <5056FA9F.6030801@inex.ie> Message-ID: On Mon, Sep 17, 2012 at 12:25 PM, Nick Hilliard wrote: > On 17/09/2012 10:47, Gert Doering wrote: >> ... I'm not sure if "every time the available pool for X is empty, just >> grab another slice of the rest and declare it to be 'available for X, but >> limited!!'" is a reasonable strategy... > > +1 > > To be clear, as proposer of this policy, I'm interested in a long term > solution for PI so that we have long term policy clarity for PI assignment > in the RIPE service region. I'm not interested in a series of stop-gap > measures. Strong agreement on both from me. I support this PDP precisely because it enables fair run-out without arbitrary limits or temporary stop-gaps. -- Richard From niels=apwg at bakker.net Mon Sep 17 16:15:23 2012 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Mon, 17 Sep 2012 16:15:23 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5056181C.7050607@inex.ie> References: <5056181C.7050607@inex.ie> Message-ID: <20120917141523.GU11613@burnout.tpb.net> * nick at inex.ie (Nick Hilliard) [Sun 16 Sep 2012, 21:10 CEST]: [..] >There are a couple of options for dealing with this: > >1. specify new time limits (e.g. receive one month in advance, hand >back one week after) I understand that the choice for a /13 to set aside for this was based on the ability to fulfill all temporary IP address space requests. Extending the time period would make this cramped, I presume. >2. don't specify time limits but allow the IPRAs to have discretion >on what seems sensible to them This sounds good on paper but will in practice just lead to requestors going "But you gave them a month, why me only a week?!" which is good for neither IPRAs nor applicants. In effect it'll end up being just like a less overt #1. >3. keep the current time limits but ask the RIPE NCC whether it >would be possible to implement a booking system. I.e. your >assignment would only be active during the requested time period, >but you would know well in advance what the options were. This isn't a good choice either but may be the least-bad of all three. Having the ASN available earlier would help somewhat with ensuring routability as IRRdb's can be updated; having the IP blocks known will help too, even if they're not yet assigned. >If anyone has opinions on which of these they prefer (or any other >suggestions on how to deal with the issue), can you either post here >or let me know off-list and I'll summarise at RIPE65 in advance of >posting a policy amendment for ripe-526 shortly after the meeting? Lengthening the lease time for temporary ASNs separately from IP number resources should be an option. A hobby gives me a vested interest in #1 so rather foolishly I hope more space can be made available to satisfy community needs, but it would already help to have the ASN and know other numbers earlier. -- Niels. -- From millnert at gmail.com Mon Sep 17 18:50:58 2012 From: millnert at gmail.com (Martin Millnert) Date: Mon, 17 Sep 2012 18:50:58 +0200 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: References: <3D7F7C92CA8EEF458B7AC7BACD7D619102F1946D586D@EXVS002.netsourcing.lan> <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> <01a401cd94b7$395f8620$ac1e9260$@de> <20120917094711.GK13776@Space.Net> <5056FA9F.6030801@inex.ie> Message-ID: <1347900658.2492.14.camel@galileo.millnert.se> On Mon, 2012-09-17 at 13:02 +0200, Richard Hartmann wrote: > On Mon, Sep 17, 2012 at 12:25 PM, Nick Hilliard wrote: > > long term policy clarity for PI assignment in the RIPE service region. Isn't it pretty clear now as it is? There will be no further PI assignments. PI is dead. Holders of PI have the option to: A) Keep holding, B) Return the address space (to become PA) C) Transfer it via a very complicated business procedure to another holder If they ever pick B, the address space returns to the non-available pool to be allocated again according to final-/8 procedures, to LIRs. (Please correct me if I'm wrong.) Ie., the long-term status of PIv4 is pretty bleak at the moment. > Strong agreement on both from me. > > I support this PDP precisely because it enables fair run-out without > arbitrary limits or temporary stop-gaps. The run-out you refer to is of the final-/8 pool, some specific space. But, assignments and allocations aren't permanent by design, and right now we're lacking in the PI transfer area. Any space returned to RIPE cannot become new PI. One result of the current policy is that there will be no more PI assignments. Obviously it's one way to remove the distinction between PA and PI I guess, by simply removing PI as a concept. :) Two fixes comes to mind: 1) 2012-04, required if we want to keep the idea of PI - otherwise we should explicitly decide on removing the distinction... 2) A transfer-policy covering C) above, i.e fix another RIPE<->Reality disconnect I'd like to see both of them. Best, Martin From lists-ripe at c4inet.net Mon Sep 17 19:00:53 2012 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 17 Sep 2012 18:00:53 +0100 Subject: [address-policy-wg] [policy-announce] 2012-04 New Draft Document Published (PI Assignments from the last /8) In-Reply-To: <1347900658.2492.14.camel@galileo.millnert.se> References: <20120915145748.GA18320@danton.fire-world.de> <00d701cd93dc$5e4bb340$1ae319c0$@globoplc.com> <5055F649.5040503@ukraine.su> <5055FFA9.201@go6.si> <01a401cd94b7$395f8620$ac1e9260$@de> <20120917094711.GK13776@Space.Net> <5056FA9F.6030801@inex.ie> <1347900658.2492.14.camel@galileo.millnert.se> Message-ID: <20120917170053.GC31709@cilantro.c4inet.net> On Mon, Sep 17, 2012 at 06:50:58PM +0200, Martin Millnert wrote: >Two fixes comes to mind: > 1) 2012-04, required if we want to keep the idea of PI - otherwise we >should explicitly decide on removing the distinction... I'd be in favour of removing the distinction altogether - ie. disconnecting the "LIR" function from the "ISP" function. AIUI, this is to be discussed at RIPE65 again? rgds, Sascha Luck From millnert at gmail.com Mon Sep 17 18:59:28 2012 From: millnert at gmail.com (Martin Millnert) Date: Mon, 17 Sep 2012 18:59:28 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5056181C.7050607@inex.ie> References: <5056181C.7050607@inex.ie> Message-ID: <1347901168.2492.19.camel@galileo.millnert.se> Hi, On Sun, 2012-09-16 at 19:19 +0100, Nick Hilliard wrote: > There's a thread on nanog-l at the moment about temporary internet assignments: > > > http://mailman.nanog.org/pipermail/nanog/2012-September/051655.html > > I had already booked a slot in the AP-WG under AOB to talk about this > because the policy is broken and needs fixing. Specifically, the > timescales specified in the policy allow the assignment to be made one week > before use: the consistent feedback is that this isn't enough time for > large conference organisers to get things organised in time. > > The problems we're trying to address are: [Devils advocate] Why must there be special treatment for conference-space (temporary assignments) at all? Why can't conferences run NAT-something+IPv6 like the rest of everything? Since networky-conferences are the most common requesters of these temp-blocks in the first place by my understanding, wouldn't that be an excellent place to start adapting to the future rather than getting special treatment and sticking to the old? Couldn't this help with dissipating clue to real networks, etc? Just a thought. Best, Martin From jim at rfc1035.com Mon Sep 17 19:36:51 2012 From: jim at rfc1035.com (Jim Reid) Date: Mon, 17 Sep 2012 18:36:51 +0100 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <1347901168.2492.19.camel@galileo.millnert.se> References: <5056181C.7050607@inex.ie> <1347901168.2492.19.camel@galileo.millnert.se> Message-ID: <3942CEFF-41C0-42C5-A996-0C5ECCDA257D@rfc1035.com> On 17 Sep 2012, at 17:59, Martin Millnert wrote: > Why can't conferences run NAT-something+IPv6 like the rest of > everything? Let's avoid this rat-hole. The issue is whether there should be temporary assignments or not. Whatever the justifications are for (not) having these or other approaches to solving those issues simply don't matter. The question here is simple and needs no refinement or qualifications. They just complicate matters and don't help. Should there be temporary assignments? Yes or no. My personal preference is to burn through all the remaining IPv4 space as quickly as possible in the (probably forlorn) hope that it puts an end to these angels on pinhead debates. :-) From marcin at leon.pl Tue Sep 18 00:05:03 2012 From: marcin at leon.pl (Marcin Kuczera) Date: Tue, 18 Sep 2012 00:05:03 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <1347901168.2492.19.camel@galileo.millnert.se> References: <5056181C.7050607@inex.ie> <1347901168.2492.19.camel@galileo.millnert.se> Message-ID: <50579E8F.10102@leon.pl> On 2012-09-17 18:59, Martin Millnert wrote: > Hi, > > On Sun, 2012-09-16 at 19:19 +0100, Nick Hilliard wrote: >> There's a thread on nanog-l at the moment about temporary internet assignments: >> >>> http://mailman.nanog.org/pipermail/nanog/2012-September/051655.html >> I had already booked a slot in the AP-WG under AOB to talk about this >> because the policy is broken and needs fixing. Specifically, the >> timescales specified in the policy allow the assignment to be made one week >> before use: the consistent feedback is that this isn't enough time for >> large conference organisers to get things organised in time. >> >> The problems we're trying to address are: > > > [Devils advocate] Why must there be special treatment for > conference-space (temporary assignments) at all? > Why can't conferences run NAT-something+IPv6 like the rest of > everything? Since networky-conferences are the most common requesters > of these temp-blocks in the first place by my understanding, wouldn't > that be an excellent place to start adapting to the future rather than > getting special treatment and sticking to the old? > > Couldn't this help with dissipating clue to real networks, etc? > > Just a thought. Clear point of view, I like it ! Regards, Marcin From niels=apwg at bakker.net Tue Sep 18 00:18:38 2012 From: niels=apwg at bakker.net (niels=apwg at bakker.net) Date: Tue, 18 Sep 2012 00:18:38 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <50579E8F.10102@leon.pl> References: <5056181C.7050607@inex.ie> <1347901168.2492.19.camel@galileo.millnert.se> <50579E8F.10102@leon.pl> Message-ID: <20120917221838.GW11613@burnout.tpb.net> * marcin at leon.pl (Marcin Kuczera) [Tue 18 Sep 2012, 00:05 CEST]: >On 2012-09-17 18:59, Martin Millnert wrote: >>[Devils advocate] Why must there be special treatment for >>conference-space (temporary assignments) at all? >>Why can't conferences run NAT-something+IPv6 like the rest of >>everything? Since networky-conferences are the most common >>requesters of these temp-blocks in the first place by my >>understanding, wouldn't that be an excellent place to start >>adapting to the future rather than getting special treatment and >>sticking to the old? >> >>Couldn't this help with dissipating clue to real networks, etc? >> >>Just a thought. > >Clear point of view, I like it ! I don't think the point of the policy is to punish people for having addressing needs. -- Niels. From millnert at gmail.com Tue Sep 18 05:50:31 2012 From: millnert at gmail.com (Martin Millnert) Date: Tue, 18 Sep 2012 05:50:31 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <20120917221838.GW11613@burnout.tpb.net> References: <5056181C.7050607@inex.ie> <1347901168.2492.19.camel@galileo.millnert.se> <50579E8F.10102@leon.pl> <20120917221838.GW11613@burnout.tpb.net> Message-ID: <1347940231.2492.24.camel@galileo.millnert.se> On Tue, 2012-09-18 at 00:18 +0200, niels=apwg at bakker.net wrote: > * marcin at leon.pl (Marcin Kuczera) [Tue 18 Sep 2012, 00:05 CEST]: > >Clear point of view, I like it ! > > I don't think the point of the policy is to punish people for having > addressing needs. Completely agree! A temporary addressing need seems much less motivated than a permanent addressing need. Jim made it simpler: We can (and should, then) discuss the temporary assignment policy as a whole. Best, Martin From ripe-wgs.cs at schiefner.de Tue Sep 18 11:50:46 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Sep 2012 11:50:46 +0200 Subject: [address-policy-wg] RIPE 553 & last /8 <-> Anycast assignments Message-ID: <505843F6.8010500@schiefner.de> All - as I have just discussed this privately with a colleague: is it the case that as a side effect of section 5.6 "Use of last /8 for PA Allocations" of RIPE 553: https://www.ripe.net/ripe/docs/ripe-553#-----use-of-last-8-for-pa-allocations there won't be any more Anycast assignments following section 6.9 "Anycasting TLD and Tier 0/1 ENUM Nameservers" of this policy: https://www.ripe.net/ripe/docs/ripe-553#-----anycastying-tld-and-tier-1-enum-nameservers either? As such 'Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region"' as this section states. I tried various ways of interpretation, but failed to come to terms eventually. Any hints, anyone? Thanks and best, Carsten From ripe-wgs.cs at schiefner.de Tue Sep 18 13:12:57 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Sep 2012 13:12:57 +0200 Subject: [address-policy-wg] RIPE 553 & last /8 <-> Anycast assignments In-Reply-To: <505843F6.8010500@schiefner.de> References: <505843F6.8010500@schiefner.de> Message-ID: <50585739.3020300@schiefner.de> Clarification: my question below only regards IPv4 Anycast assignments, of course. Best, Carsten On 18.09.2012 11:50, Carsten Schiefner wrote: > All - > > as I have just discussed this privately with a colleague: is it the case > that as a side effect of section 5.6 "Use of last /8 for PA Allocations" > of RIPE 553: > > https://www.ripe.net/ripe/docs/ripe-553#-----use-of-last-8-for-pa-allocations > > > there won't be any more Anycast assignments following section 6.9 > "Anycasting TLD and Tier 0/1 ENUM Nameservers" of this policy: > > https://www.ripe.net/ripe/docs/ripe-553#-----anycastying-tld-and-tier-1-enum-nameservers > > > either? > > As such 'Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup > services are subject to the policies described in the RIPE Document > entitled "Contractual Requirements for Provider Independent Resource > Holders in the RIPE NCC Service Region"' as this section states. > > I tried various ways of interpretation, but failed to come to terms > eventually. > > Any hints, anyone? > > Thanks and best, > > Carsten From sander at steffann.nl Tue Sep 18 13:42:50 2012 From: sander at steffann.nl (Sander Steffann) Date: Tue, 18 Sep 2012 14:42:50 +0300 Subject: [address-policy-wg] RIPE 553 & last /8 <-> Anycast assignments In-Reply-To: <505843F6.8010500@schiefner.de> References: <505843F6.8010500@schiefner.de> Message-ID: Hello Carsten, > as I have just discussed this privately with a colleague: is it the case that as a side effect of section 5.6 "Use of last /8 for PA Allocations" of RIPE 553: > > https://www.ripe.net/ripe/docs/ripe-553#-----use-of-last-8-for-pa-allocations > > there won't be any more Anycast assignments following section 6.9 "Anycasting TLD and Tier 0/1 ENUM Nameservers" of this policy: > > https://www.ripe.net/ripe/docs/ripe-553#-----anycastying-tld-and-tier-1-enum-nameservers > > either? Correct. We currently have from the last /8: - /22 allocations to LIRs - /22-/24 assignments to IXPs All other IPv4 allocation and assignment policies have now become obsolete. > As such 'Assignments for authoritative TLD or ENUM Tier 0/1 DNS lookup services are subject to the policies described in the RIPE Document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region"' as this section states. > > I tried various ways of interpretation, but failed to come to terms eventually. > > Any hints, anyone? This text applies: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows". The 'only' part stops all other distribution. The contractual requirements are still in place, but no new allocations or assignments will be made. Does this answer your question? - Sander From ripe-wgs.cs at schiefner.de Tue Sep 18 14:06:12 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Sep 2012 14:06:12 +0200 Subject: [address-policy-wg] RIPE 553 & last /8 <-> Anycast assignments In-Reply-To: References: <505843F6.8010500@schiefner.de> Message-ID: <505863B4.60301@schiefner.de> Hi Sander, On 18.09.2012 13:42, Sander Steffann wrote: > [...] > > Does this answer your question? yes. Maybe not in my most preferred way - but it does. Thanks and best, -C. From ripe-wgs.cs at schiefner.de Tue Sep 18 14:23:35 2012 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Sep 2012 14:23:35 +0200 Subject: [address-policy-wg] RIPE 553 & last /8 <-> Anycast assignments In-Reply-To: <505863B4.60301@schiefner.de> References: <505843F6.8010500@schiefner.de> <505863B4.60301@schiefner.de> Message-ID: <505867C7.7020101@schiefner.de> Hi Sander, me once more to get out some ambiguity of what I have written below: On 18.09.2012 14:06, Carsten Schiefner wrote: >On 18.09.2012 13:42, Sander Steffann wrote: >> [...] >> >> Does this answer your question? > > yes. Maybe not in my most preferred way - but it does. Your kind of answer and its grade of granularity is entirely fine. It's just that its content is not what I have whished for most... Best, Carsten From Woeber at CC.UniVie.ac.at Tue Sep 18 18:51:32 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Sep 2012 18:51:32 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <20120917141523.GU11613@burnout.tpb.net> References: <5056181C.7050607@inex.ie> <20120917141523.GU11613@burnout.tpb.net> Message-ID: <5058A694.5000107@CC.UniVie.ac.at> niels=apwg at bakker.net wrote: > * nick at inex.ie (Nick Hilliard) [Sun 16 Sep 2012, 21:10 CEST]: > [..] > >> There are a couple of options for dealing with this: >> >> 1. specify new time limits (e.g. receive one month in advance, hand >> back one week after) > > > I understand that the choice for a /13 to set aside for this was based > on the ability to fulfill all temporary IP address space requests. > Extending the time period would make this cramped, I presume. Well, if I am not mistaken, this has been in effect for a while already. Thus, may I ask the IPRAs to give us some real numbers (max# of concurrently active assignments, minimum/average/max size of blocks assigned) and any other feeback that may be helpful? In general, I am in favour of #1, because it makes it easy for both sides to work in this framework, without bickering, finger-pointing and inventing good arguments. If it turns out, that there *is* competition in the future, we can *then* implement remedies. I would count on the NCC to give an early heads-up :-) >> 2. don't specify time limits but allow the IPRAs to have discretion >> on what seems sensible to them > > > This sounds good on paper but will in practice just lead to requestors > going "But you gave them a month, why me only a > week?!" which is good for neither IPRAs nor applicants. In effect it'll > end up being just like a less overt #1. > > >> 3. keep the current time limits but ask the RIPE NCC whether it would >> be possible to implement a booking system. I.e. your assignment would >> only be active during the requested time period, but you would know >> well in advance what the options were. > > > This isn't a good choice either but may be the least-bad of all three. I strongly dislike that option, it just complicates things and adds a "simple" mechanism to make mistakes and to have announcements leaking. > Having the ASN available earlier would help somewhat with ensuring > routability as IRRdb's can be updated; having the IP blocks known will > help too, even if they're not yet assigned. Whatever we end up with, the ASN boundaries should at least be aligned with the address assignment period, probably even more generous. Given that ASN32 is there, there shouldn't be a shortage in the next few years :-) >> If anyone has opinions on which of these they prefer (or any other >> suggestions on how to deal with the issue), can you either post here >> or let me know off-list and I'll summarise at RIPE65 in advance of >> posting a policy amendment for ripe-526 shortly after the meeting? > > > Lengthening the lease time for temporary ASNs separately from IP number > resources should be an option. > > A hobby gives me a vested interest in #1 so rather foolishly I hope more > space can be made available to satisfy community needs, but it would > already help to have the ASN and know other numbers earlier. Whether we need this policy or not is a different aspect. And I am waiting for the club to hit some head/s for trying to see a bigger picture, like it was happening to me a short while ago on a different topic ;-) > -- Niels. Wilfried From alexlh at ripe.net Wed Sep 19 13:03:49 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 19 Sep 2012 13:03:49 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: <5058A694.5000107@CC.UniVie.ac.at> References: <5056181C.7050607@inex.ie> <20120917141523.GU11613@burnout.tpb.net> <5058A694.5000107@CC.UniVie.ac.at> Message-ID: Dear Wilfried, >> I understand that the choice for a /13 to set aside for this was based >> on the ability to fulfill all temporary IP address space requests. >> Extending the time period would make this cramped, I presume. > > Well, if I am not mistaken, this has been in effect for a while already. > > Thus, may I ask the IPRAs to give us some real numbers (max# of concurrently > active assignments, minimum/average/max size of blocks assigned) and any > other feeback that may be helpful? When deciding on the size of the temporary assignment pool, we did indeed look at the number of concurrent outstanding assignments in the prior years. The maximum amount of space that has been assigned concurrently since the temporary assignment policy has been implemented is as follows: - 2x /20 - 1x /22 - 1x /24 total: /19, /22, /24 The temporary assignment pool has not been heavily used yet in 2012. Part of the reason for this is probably that some of the events that traditionally require large temporary assignments (~ /16) happen only at the end of the year or in odd-numbered years. I hope this answers your questions, if you have any others, please do not hesitate to ask. Best regards, Alex Le Heux Policy Implementation Co-ordinator From Woeber at CC.UniVie.ac.at Wed Sep 19 13:20:52 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 19 Sep 2012 13:20:52 +0200 Subject: [address-policy-wg] Temporary Internet Assignments policy In-Reply-To: References: <5056181C.7050607@inex.ie> <20120917141523.GU11613@burnout.tpb.net> <5058A694.5000107@CC.UniVie.ac.at> Message-ID: <5059AA94.6000902@CC.UniVie.ac.at> Alex Le Heux wrote: > Dear Wilfried, > > >>>I understand that the choice for a /13 to set aside for this was based >>>on the ability to fulfill all temporary IP address space requests. >>>Extending the time period would make this cramped, I presume. >> >>Well, if I am not mistaken, this has been in effect for a while already. >> >>Thus, may I ask the IPRAs to give us some real numbers (max# of concurrently >>active assignments, minimum/average/max size of blocks assigned) and any >>other feeback that may be helpful? > > > When deciding on the size of the temporary assignment pool, we did indeed look at the number of concurrent outstanding assignments in the prior years. > > The maximum amount of space that has been assigned concurrently since the temporary assignment policy has been implemented is as follows: > > - 2x /20 > - 1x /22 > - 1x /24 > > total: /19, /22, /24 > > The temporary assignment pool has not been heavily used yet in 2012. Part of the reason for this is probably that some of the events that traditionally require large temporary assignments (~ /16) happen only at the end of the year or in odd-numbered years. > > I hope this answers your questions, Indeed, thank you very much! Wilfried > if you have any others, please do not hesitate to ask. > > Best regards, > > Alex Le Heux > Policy Implementation Co-ordinator From emadaio at ripe.net Mon Sep 24 14:14:44 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 24 Sep 2012 14:14:44 +0200 Subject: [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: Dear Colleagues, The Discussion Period for the proposal 2012-02,"Policy for Inter-RIR Transfers of IPv4 Address Space", has been extended until 22 October 2012. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-02 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Mon Sep 24 14:37:36 2012 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 24 Sep 2012 14:37:36 +0200 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) Message-ID: Dear Colleagues, The text of the policy proposal 2012-03, "Intra-RIR transfer policy" has been revised. We have published the new version (version 2.0) today. As a result a new Discussion Phase is set for the proposal until 22 October 2012. Highlights of the changes: -additional wording on the second paragraph of section 5.5 You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-03 We encourage you to review this policy proposal and send your comments to before 22 October 2012. Regards, Emilio Madaio Policy Development Officer RIPE NCC From tore.anderson at redpill-linpro.com Mon Sep 24 15:27:12 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Mon, 24 Sep 2012 15:27:12 +0200 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) In-Reply-To: <20120924123744.72848C39E5@mailhub.linpro.no> References: <20120924123744.72848C39E5@mailhub.linpro.no> Message-ID: <50605FB0.1020209@redpill-linpro.com> * Emilio Madaio > We encourage you to review this policy proposal and send your comments > to before 22 October 2012. I am really struggling with this sentence: ?Other than for an additional allocation, for the purpose of determining need, a period of 24 months is used in evaluating a transferred allocation.? The interpretation I eventually ended up with, is that it means that the new 24 month period only comes into effect for initial allocations, i.e., only for transfers where the recipient LIR holds no IPv4 PA allocations. For transfers where the recipient LIR has an additional allocation, the effective need period will still be three months. Is that correct? In any case, I think it would be good this sentence could be rewritten so it is easier to understand. Another thing I am wondering about, is the new 24 month period. Prior to ?Run Out Fairly?, the period was 12 months. This was determined by 2006-06, which intended to harmonise the need period across the five regions. With that in mind, I would like to see why 24 months was chosen. Is 2006-06's rationale no longer valid? What are the need periods currently used for allocation transfers in the other regions? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From tore.anderson at redpill-linpro.com Tue Sep 25 07:25:50 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 25 Sep 2012 07:25:50 +0200 Subject: [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space) In-Reply-To: <20120924123152.8BF15C39E5@mailhub.linpro.no> References: <20120924123152.8BF15C39E5@mailhub.linpro.no> Message-ID: <5061405E.5090904@redpill-linpro.com> * Emilio Madaio > The Discussion Period for the proposal 2012-02,"Policy for Inter-RIR > Transfers of IPv4 Address Space", has been extended until 22 October > 2012. I support this proposal, but wonder why it specifically refers to LIRs rather than something generic like ?organisations?? That excludes transfers of direct assignments to/from End Users [who are not also LIRs]. In other places, the text refers to ?any IPv4 address space?, which seems to indicate that direct assignments are in scope, too. While it is the case that the RIPE region currently does not have a transfer policy for assignments, that may change in the future. I don't know about other regions (but obviously policies may change here too). Some hypothetical examples (I am assuming we are not running into any restrictions found in the remote region's transfer policy): 1) A RIPE region LIR wants to transfer and unused IPv4 allocation to an out-of-region End User (who is not a LIR), which will register the prefix in the Destination RIR's database as a direct assignment. 2) Same as #1, but the End User happens to also be a LIR. 3) An out-of-region End User (who is not a LIR), has a unused IPv4 direct assignment he wishes to transfer to a RIPE region LIR, who intend to register the prefix in the RIPE database as ALLOCATED PA. 4) Same as #3, only that the End User happens to also be a LIR. As I understand the proposed policy, #1 and #3 would not be allowed, but #2 and #4 would. Is my understanding correct? Also, assuming that a transfer policy has since been established in the RIPE region covering transfers of direct assignments: 5) Out-of-region End User wants to transfer a direct assignment to a RIPE region End User. Neither are LIRs. This would not be permitted by this policy either, correct? Finally, an editorial/language feedback: ?Apart from transfers of address space within the service region of the RIPE NCC, this policy defines the framework that outlines what specific rules apply to IPv4 address space transfers in between the different RIR regions.? Native speakers please correct me if I'm wrong, but I've been taught that if you say ?Apart from This, That? in English, the logical interpretation of that statement is "This AND That" (with an emphasis on "That"). It is however fairly clear from reading the rest of the proposal that the intended logical meaning in this case is "not(This) AND That". I don't think it particularly good form to start a policy with a statement of what it *isn't*, so I would suggest simply deleting the entire ?Apart from transfers of address space within the service region of the RIPE NCC,? text. It is redundant in any case, as section 1.1 clearly declares in-region transfers as being out of scope. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From sandrabrown at ipv4marketgroup.com Tue Sep 25 14:44:39 2012 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 25 Sep 2012 05:44:39 -0700 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) Message-ID: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> Tore Anderson stated I am really struggling with this sentence: ?Other than for an additional allocation, for the purpose of determining need, a period of 24 months is used in evaluating a transferred allocation.? The intent is that 24 months should be the the period for all allocations. I will change the wording to: A period of 24 months is used in evaluating a transferred allocation. Tore also stated: Another thing I am wondering about, is the new 24 month period. Prior to ?Run Out Fairly?, the period was 12 months. This was determined by 2006-06, which intended to harmonise the need period across the five regions. With that in mind, I would like to see why 24 months was chosen. Is 2006-06's rationale no longer valid? What are the need periods currently used for allocation transfers in the other regions? The need period in the ARIN region is 24 months and the need period in the APNIC region is 12 months. Thanks, Sandra Brown IPv4 Market Group sandrabrown at ipv4marketgroup.com From sandrabrown at ipv4marketgroup.com Tue Sep 25 14:52:20 2012 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 25 Sep 2012 05:52:20 -0700 Subject: [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space) Message-ID: <20120925055220.ec289651d84890fcbef5f195936e1217.eab05b7f34.wbe@email17.secureserver.net> Thank you for your comments Tore. --------------------------------------------------------------- I support this proposal, but wonder why it specifically refers to LIRs rather than something generic like ?organisations?? That excludes transfers of direct assignments to/from End Users [who are not also LIRs]. In other places, the text refers to ?any IPv4 address space?, which seems to indicate that direct assignments are in scope, too. --------------------------------------------------------------- I am quite willing to change the wording from LIR's to Organizations if all agree. Then all five transfer examples defined by Tore would be allowed. --------------------------------------------------------------- Finally, an editorial/language feedback: ?Apart from transfers of address space within the service region of the RIPE NCC, this policy defines the framework that outlines what specific rules apply to IPv4 address space transfers in between the different RIR regions.? --------------------------------------------------------------- I agree with Tore's editorial change. This sentence will now read: This policy defines the framework that outlines specific rules which apply to IPv4 address space transfer between the RIR regions. Thank you. Sandra Brown IPv4 Market Group sandrabrown at ipv4marketgroup.com From tore.anderson at redpill-linpro.com Tue Sep 25 15:10:55 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 25 Sep 2012 15:10:55 +0200 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) In-Reply-To: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> References: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> Message-ID: <5061AD5F.5030007@redpill-linpro.com> * sandrabrown at ipv4marketgroup.com > The intent is that 24 months should be the the period for all > allocations. I will change the wording to: > > A period of 24 months is used in evaluating a transferred allocation. Thank you for clarifying. This does not actually state what those 24 months are used for, though. If I may, I'd suggest an alternative wording, based on the existing one that defines the (obsolete) need period for NCC-to-LIR transfers in section 5.0: ?The RIPE NCC approves transfers of allocations to LIRs to meet their needs for a period of up to 24 months.? (Or perhaps it would be better English to use "that" instead of the first "to"? I'm not a native speaker, so not I'm not sure here.) > Tore also stated: > Another thing I am wondering about, is the new 24 month period. Prior to > ?Run Out Fairly?, the period was 12 months. This was determined by > 2006-06, which intended to harmonise the need period across the five > regions. With that in mind, I would like to see why 24 months was > chosen. Is 2006-06's rationale no longer valid? What are the need > periods currently used for allocation transfers in the other regions? > > The need period in the ARIN region is 24 months and the need period in > the APNIC region is 12 months. Thank you again. Do you know whether or not there are any active efforts in any of those regions to harmonise the periods (in other words change it to 24 months in the APNIC region, or to 12 months in the ARIN region)? -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From farmer at umn.edu Tue Sep 25 16:18:41 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 25 Sep 2012 09:18:41 -0500 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) In-Reply-To: <5061AD5F.5030007@redpill-linpro.com> References: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> <5061AD5F.5030007@redpill-linpro.com> Message-ID: <5061BD41.6070006@umn.edu> On 9/25/12 08:10 CDT, Tore Anderson wrote: > Thank you again. Do you know whether or not there are any active efforts > in any of those regions to harmonise the periods (in other words change > it to 24 months in the APNIC region, or to 12 months in the ARIN region)? APNIC-Prop-104 is under consideration at APNIC as we speak, and would move APNIC to 24-months. http://www.apnic.net/policy/proposals/prop-104 ARIN-2011-12 was implemented in February, please note that 36-months was also discussed during that process and another proposal ARIN-prop-176 pushed from 60-months. So, I don't believe ARIN returning to 12-months is a realistic expectation, personally I see ARIN either remaining at 24 months or maybe going to 36 months if justified after additional experience with transfers. https://www.arin.net/policy/proposals/2011_12.html http://lists.arin.net/pipermail/arin-ppml/2012-June/025352.html -- =============================================== David Farmer Email:farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From tore.anderson at redpill-linpro.com Tue Sep 25 19:15:08 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 25 Sep 2012 19:15:08 +0200 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) In-Reply-To: <5061BD41.6070006@umn.edu> References: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> <5061AD5F.5030007@redpill-linpro.com> <5061BD41.6070006@umn.edu> Message-ID: <5061E69C.4020607@redpill-linpro.com> * David Farmer > On 9/25/12 08:10 CDT, Tore Anderson wrote: > >> Thank you again. Do you know whether or not there are any active efforts >> in any of those regions to harmonise the periods (in other words change >> it to 24 months in the APNIC region, or to 12 months in the ARIN region)? > > APNIC-Prop-104 is under consideration at APNIC as we speak, and would > move APNIC to 24-months. > > http://www.apnic.net/policy/proposals/prop-104 > > ARIN-2011-12 was implemented in February, please note that 36-months was > also discussed during that process and another proposal ARIN-prop-176 > pushed from 60-months. So, I don't believe ARIN returning to 12-months > is a realistic expectation, personally I see ARIN either remaining at 24 > months or maybe going to 36 months if justified after additional > experience with transfers. > > https://www.arin.net/policy/proposals/2011_12.html > http://lists.arin.net/pipermail/arin-ppml/2012-June/025352.html Thank you for these pointers. So the current ARIN period is no doubt 24 months, and the APNIC prop-104 page says its status is ?reached consensus at APNIC 34?. I guess this means, then, that 24 months is the single best value to change the "alloc-transfer-need-period" to in the RIPE region in order to best harmonise our policy with the other regions, at least for now. Ok, I'm sold. Harmony between the regions is a good ting. So, on the condition that the new policy text is made clearer, support. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From mueller at syr.edu Tue Sep 25 22:19:23 2012 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 25 Sep 2012 20:19:23 +0000 Subject: [address-policy-wg] 2012-03 Discussion Period extended until 22 October 2012 (Intra-RIR transfer policy) In-Reply-To: <5061AD5F.5030007@redpill-linpro.com> References: <20120925054439.ec289651d84890fcbef5f195936e1217.2227ffedfa.wbe@email17.secureserver.net> <5061AD5F.5030007@redpill-linpro.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD223C223@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > Thank you for clarifying. This does not actually state what those 24 > months are used for, though. If I may, I'd suggest an alternative > wording, based on the existing one that defines the (obsolete) need > period for NCC-to-LIR transfers in section 5.0: > > ?The RIPE NCC approves transfers of allocations to LIRs to meet their > needs for a period of up to 24 months.? > > (Or perhaps it would be better English to use "that" instead of the > first "to"? I'm not a native speaker, so not I'm not sure here.) No, the first one is better. > Thank you again. Do you know whether or not there are any active efforts > in any of those regions to harmonise the periods (in other words change > it to 24 months in the APNIC region, or to 12 months in the ARIN region)? There are no plans or proposals I am aware of to change it back to 12 months in ARIN. There are some discussions of increasing the free pool time horizon from 3 months to a long period, probably 12 months. There have also been proposals (unsuccessful) to raise it to 60 months in the ARIN region. But the main reason that failed was that the 24 month period only went into effect early in 2012, and they want to give it time to function. From Woeber at CC.UniVie.ac.at Thu Sep 27 10:00:24 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 27 Sep 2012 10:00:24 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: References: Message-ID: <50640798.5040200@CC.UniVie.ac.at> Before formally submitting my statement of support, I'd like to ask for clarification on the proposed text for 6.3, specifically: " ...this should be at least 50% of the space unless special circumstances are defined. " Which party would "define" such "special cicumstances" and which party would review/grant/deny? Thanks, Wilfried From tore.anderson at redpill-linpro.com Thu Sep 27 11:27:32 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 27 Sep 2012 11:27:32 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <50640798.5040200@CC.UniVie.ac.at> References: <50640798.5040200@CC.UniVie.ac.at> Message-ID: <50641C04.4020706@redpill-linpro.com> * Wilfried Woeber > Before formally submitting my statement of support, I'd like to ask > for clarification on the proposed text for 6.3, specifically: > > " ...this should be at least 50% of the space unless special > circumstances are defined. " > > Which party would "define" such "special cicumstances" and which > party would review/grant/deny? The NCC, I presume... I would like to make it very clear that this exact formulation was in the original policy document (prior to Run Out Fairly), so it isn't anything new. (This is also the case for all other text that this proposal adds.) See: Maybe Alex or someone else from the NCC could shed some light on how this part of the policy was interpreted prior to the implementation of Run Out Fairly? Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From tore.anderson at redpill-linpro.com Thu Sep 27 11:28:33 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 27 Sep 2012 11:28:33 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <50641C04.4020706@redpill-linpro.com> References: <50640798.5040200@CC.UniVie.ac.at> <50641C04.4020706@redpill-linpro.com> Message-ID: <50641C41.4010706@redpill-linpro.com> * Tore Anderson > I would like to make it very clear that this exact formulation was in > the original policy document (prior to Run Out Fairly), so it isn't > anything new. (This is also the case for all other text that this > proposal adds.) > > See: Whops. See: http://www.ripe.net/ripe/docs/ripe-498 -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From Ragnar.Anfinsen at altibox.no Thu Sep 27 11:22:18 2012 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Thu, 27 Sep 2012 09:22:18 +0000 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <20120903135034.0642D9C007@asav8.lyse.net> Message-ID: This proposal makes a lot of sense and I support it. /Ragnar On 03.09.12 15:50, "Emilio Madaio" wrote: > > >Dear Colleagues > >A proposed change to RIPE Document ripe-553, "IPv4 Address Allocation >and Assignment Policy for the RIPE NCC Service Region", is now >available for discussion. > > >You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 > >We encourage you to review this proposal and send your comments to > before 1 October 2012. > >Regards > >Emilio Madaio >Policy Development Officer >RIPE NCC > > From tore.anderson at redpill-linpro.com Thu Sep 27 11:44:45 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 27 Sep 2012 11:44:45 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <50641C04.4020706@redpill-linpro.com> References: <50640798.5040200@CC.UniVie.ac.at> <50641C04.4020706@redpill-linpro.com> Message-ID: <5064200D.9090500@redpill-linpro.com> * Tore Anderson > * Wilfried Woeber > >> Before formally submitting my statement of support, I'd like to ask >> for clarification on the proposed text for 6.3, specifically: >> >> " ...this should be at least 50% of the space unless special >> circumstances are defined. " >> >> Which party would "define" such "special cicumstances" and which >> party would review/grant/deny? > > The NCC, I presume... > > I would like to make it very clear that this exact formulation was in > the original policy document (prior to Run Out Fairly), so it isn't > anything new. (This is also the case for all other text that this > proposal adds.) Oh my. There is a problem here. See: http://www.ripe.net/ripe/policies/proposals/2009-03/draft The formulation you're referring to, is present as ?original text?. It was also present in ripe-449. When preparing my proposal, I used the above page and did the exact opposite. However, I had overlooked that the ripe-449 had been obsoleted by some other policy change prior to the implementation of Run Out Fairly. Which means that my proposal, as currently stated, reverts (parts) of that other proposal also. That is not the intention of this policy at all. I will try to have Emilio spin new version that actually reverts the changes made by Run Out Fairly, and only those. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From tore.anderson at redpill-linpro.com Thu Sep 27 12:24:50 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 27 Sep 2012 12:24:50 +0200 Subject: [address-policy-wg] 2012-06 New Policy Proposal (Revert "Run Out Fairly" after IPv4 depletion) In-Reply-To: <5064200D.9090500@redpill-linpro.com> References: <50640798.5040200@CC.UniVie.ac.at> <50641C04.4020706@redpill-linpro.com> <5064200D.9090500@redpill-linpro.com> Message-ID: <50642972.7040103@redpill-linpro.com> * Tore Anderson > Oh my. There is a problem here. Hmm. I think that if there is a problem, it's just with me sending out e-mails too quickly. :-) I think I ended up confusing my own proposal with the last /8 proposal... So unless I'm mistaken, the policy document immediately preceding the implementation of Run Out Fairly, was: http://www.ripe.net/ripe/docs/ripe-471 The first document that contained Run Out Fairly, and that obsoleted ripe-471, was: http://www.ripe.net/ripe/docs/ripe-484 Having double-checked the differences between the two, I do believe that the changes my proposal would do, is what I've advertised - the exact differences between the policy after and before the implementation of Run Out Fairly. The sentence you pointed out, about the ?special circumstances?, was present in ripe-471, at least. My apologies for crying wolf here. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From info at leadertelecom.nl Thu Sep 27 12:13:28 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 27 Sep 2012 14:13:28 +0400 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses Message-ID: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> Dear Community, 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. ? This idea was presented on Address Policy Working Group, Thursday 27 Sep, RIPE 65, Amsterdam. ? -- Alexey Ivanov Owner & General Director LeaderTelecom Ltd. Owner & Managing Director LeaderTelecom B.V. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore.anderson at redpill-linpro.com Thu Sep 27 14:49:26 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 27 Sep 2012 14:49:26 +0200 Subject: [address-policy-wg] [Ticket#2012092701011684] Sub-allocations - fast and simple re-using IP-addresses In-Reply-To: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> References: <1348740808.468695.586845327.241366.2@otrs.hostingconsult.ru> Message-ID: <50644B56.8070805@redpill-linpro.com> * 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 - http://www.redpill-linpro.com/ From info at leadertelecom.nl Thu Sep 27 17:46:22 2012 From: info at leadertelecom.nl (LeaderTelecom B.V.) Date: Thu, 27 Sep 2012 19:46:22 +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: <1348760782.172674.513420591.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? I think doesn't make any sense to approve in RIPE sub-allocations. Earlier it was important, while count of IP addresses were very limited. And RIPE tried to give as much IPs as need LIR/user/etc. For now we don't have IPv4 in RIPE. And it is not necessary to control sub-allocations. It is a good alternative for temporary transfers. For example, if you go to register buying house and government will ask why you need house, how many rooms do you need, and etc. And they can approve or reject your request. It is not necessary. If you need IPs and you found IPs - of course you will pay money for this IPs and you will get as much as you need.? Less work for RIPE, less bureaucracy, simple re-usage - just register and go. You need just several minutes to register records in RIPE database. -- Kind regards, Alexey Ivanov LeaderTelecom B.V.? 27.09.2012 16:50 - 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: