From arash_mpc at parsun.com Wed Jul 1 02:21:21 2015 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 1 Jul 2015 10:21:21 +1000 Subject: [address-policy-wg] Opposing policy 2015-01 Message-ID: <001f01d0b393$df624c30$9e26e490$@parsun.com> Hi, I oppose policy 2015-01 because it can affect LIRs which are not new but they recently have received their /22 from last /8. (For example an LIR which is registered in 2010 and just received its /22) the LIR is not established to just receive the /22 but it has to wait for 2 years to be able to transfer it and I don't see any reason for this limitation. As a side effect it makes it harder for IP distribution which is the main goal of RIPE. Regards, Arash Naderpour From garry at nethinks.com Wed Jul 1 06:20:41 2015 From: garry at nethinks.com (Garry Glendown) Date: Wed, 1 Jul 2015 06:20:41 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <001f01d0b393$df624c30$9e26e490$@parsun.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> Message-ID: <55936A99.6040409@nethinks.com> Hi, > I oppose policy 2015-01 because it can affect LIRs which are not new but > they recently have received their /22 from last /8. (For example an LIR > which is registered in 2010 and just received its /22) > the LIR is not established to just receive the /22 but it has to wait for 2 I may misunderstand your reasoning, but that's why 2015-1 was desgined to do ... keep "dummy-LIRs" from being set up just to move the /22 to another LIR. > limitation. As a side effect it makes it harder for IP distribution which is > the main goal of RIPE. Actually, it aids it, as it keeps existing LIRs from going around and grabbing the available IP spaces and thereby keeping new entries from getting any ... please look at the ARIN region - they are down to ~140 /22 (fragmented into /23 and /24), which is still dropping quickly ... in contrast, RIPE's policies habe helped to still have a pool that might still last ~5 years ... -garry From arash_mpc at parsun.com Wed Jul 1 07:23:54 2015 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 1 Jul 2015 15:23:54 +1000 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <55936A99.6040409@nethinks.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> <55936A99.6040409@nethinks.com> Message-ID: <001001d0b3be$26859070$7390b150$@parsun.com> Hi, I'm not sure what you mean from dummy-LIRs but I think you mean the ones that just set up to get a single /22 to transfer it, am I right? If yes, It cannot keep "dummy-LIRs" from being set up, it just make it less attractive. But My argument was not about "dummy-LIRs set up", I'm talking about the LIRs that are not new and are already registered years ago, (before RIPE NCC starts distribution of last /8, before 2012) now if they apply to receive their last /22 why they have to wait for 2 years to be able to transfer them to others. (that makes IP distribution more difficult) It was not mandatory to receive last /22 and they are plenty of LIRs that are still using their existing allocations without getting their last /22. Not every olds LIR received its /22 till now and this 2015-01 can affect them too. Is it something supposed to be happened? I oppose this proposal because it has unnecessary effect on some of the genuine LIRs too. Arash Naderpour -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Garry Glendown Sent: Wednesday, July 01, 2015 2:21 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Opposing policy 2015-01 Hi, > I oppose policy 2015-01 because it can affect LIRs which are not new > but they recently have received their /22 from last /8. (For example > an LIR which is registered in 2010 and just received its /22) the LIR > is not established to just receive the /22 but it has to wait for 2 I may misunderstand your reasoning, but that's why 2015-1 was desgined to do ... keep "dummy-LIRs" from being set up just to move the /22 to another LIR. > limitation. As a side effect it makes it harder for IP distribution > which is the main goal of RIPE. Actually, it aids it, as it keeps existing LIRs from going around and grabbing the available IP spaces and thereby keeping new entries from getting any ... please look at the ARIN region - they are down to ~140 /22 (fragmented into /23 and /24), which is still dropping quickly ... in contrast, RIPE's policies habe helped to still have a pool that might still last ~5 years ... -garry From shahin at gharghi.ir Wed Jul 1 07:29:42 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Tue, 30 Jun 2015 22:29:42 -0700 Subject: [address-policy-wg] We need IPv4 transfers Message-ID: Hi Although this is the last call, and I have been criticizing the usefulness of this proposal in protecting the remained IPv4, I am not still logically replied. Those questions were: 1- How can we prevent transfers by accepting this proposal? We can always transfer by taking ownership of the sellers company. So this proposal would not be beneficial at all. 2- According to the 1st question, and knowing that , there are some dealers who get IP's from RIPE NCC and sell them to customers, Why wouldn?t RIPE NCC sell the IP's directly to them? (By allowing those companies to register new LIR and get new /22). 3- Obviously the internet is increasing and companies need more IP's, and there are some other IP's available in RIPE NCC, Why shouldn't we use them? The people won't think about IPv6 seriously unless they see there is no other IPv4. 4- If people are unable to transfer IP's. They will lend them. (The proposal won't help again) I would be glad to add my arguments to Sander's conclusion. -- Shahin Gharghi From shahin at gharghi.ir Wed Jul 1 07:38:03 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Tue, 30 Jun 2015 22:38:03 -0700 Subject: [address-policy-wg] Opposing policy 2015-01 Message-ID: Hi I agree with Arash and also people can transfer their IP's after two years. So the proposal doesn't help again. -- Shahin Gharghi From garry at nethinks.com Wed Jul 1 08:04:02 2015 From: garry at nethinks.com (Garry Glendown) Date: Wed, 1 Jul 2015 08:04:02 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: Message-ID: <559382D2.9090608@nethinks.com> On 01.07.2015 07:38, Shahin Gharghi wrote: > Hi > > I agree with Arash and also people can transfer their IP's after two > years. So the proposal doesn't help again. > > So, in essence, you would rather do NOTHING than accept the proposal, which at least - at the moment - significantly increases cost for IP-traders, while at the same time giving us additional time to come up with a better solution (which probably takes another year to come up with, discuss, optimize, and pass)? Why don't you enlighten us how you would improve 2015-1 in order to prevent abuse of the current policy? If you have any good ideas, I believe all of the people on the list would appreciate any constructive input? -garry From garry at nethinks.com Wed Jul 1 08:13:00 2015 From: garry at nethinks.com (Garry Glendown) Date: Wed, 1 Jul 2015 08:13:00 +0200 Subject: [address-policy-wg] We need IPv4 transfers In-Reply-To: References: Message-ID: <559384EC.7020006@nethinks.com> > Although this is the last call, and I have been criticizing the > usefulness of this proposal in protecting the remained IPv4, I am not > still logically replied. > Those questions were: > 1- How can we prevent transfers by accepting this proposal? We can > always transfer by taking ownership of the sellers company. So this > proposal would not be beneficial at all. But by - for now - accepting the proposal, at least the cost will be increased, making the abuse of the last-/8 policies more costly (additional year of LIR fees), while not increasing cost for legitimate uses ... > 2- According to the 1st question, and knowing that , there are some > dealers who get IP's from RIPE NCC and sell them to customers, Why > wouldn?t RIPE NCC sell the IP's directly to them? (By allowing those > companies to register new LIR and get new /22). The point is not for RIPE to make money on distributing IP addresses - if they wanted to do that, I believe it would only take a couple days to deplete the remaining IP addresses available ... The point is to conserve IP addresses in order to allow new companies who do not have IPs but require at least a minimal set of v4-addresses to survive until v6 is universally available to all users ... (which will most likely take quite a while, given the current state) > 3- Obviously the internet is increasing and companies need more IP's, > and there are some other IP's available in RIPE NCC, Why shouldn't we > use them? The people won't think about IPv6 seriously unless they see > there is no other IPv4. Anybody who needs to see even more scarcity of v4-addresses (e.g. ARIN only has the equivalent of ~140 /22 left, and it's dropping quickly!) is either stupid or doesn't want to see the business case for getting IPv6 up and running ... > 4- If people are unable to transfer IP's. They will lend them. (The > proposal won't help again) Again, the cost for an LIR who was just set up to get a /22 has increased due to the fact they have to be a member for two years instead of one ... plus the uncertainty as to what improvements the RIPE community will add to the policies in order to help legitimate use of last-/8 policies ... -garry From shahin at gharghi.ir Wed Jul 1 08:31:53 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Tue, 30 Jun 2015 23:31:53 -0700 Subject: [address-policy-wg] Opposing policy 2015-01 Message-ID: Dear Garry If you read my previous messages you can find my solution. We have to discuss about accepting this proposals or not. We will talk about other solutions in other proposals. -- Shahin Gharghi From bengan at resilans.se Wed Jul 1 09:32:47 2015 From: bengan at resilans.se (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Wed, 01 Jul 2015 09:32:47 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: Message-ID: <5593979F.9010300@resilans.se> Den 2015-07-01 08:31, Shahin Gharghi skrev: > Dear Garry > If you read my previous messages you can find my solution. It's sort of difficult to follow your previous thoughts due to the lack of your ability to keep same discussion in same thread. Please, don't break the threads. -- Bengt G?rd?n Resilans AB From garry.glendown at nethinks.com Wed Jul 1 08:19:14 2015 From: garry.glendown at nethinks.com (Garry Glendown) Date: Wed, 1 Jul 2015 08:19:14 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <001001d0b3be$26859070$7390b150$@parsun.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> <55936A99.6040409@nethinks.com> <001001d0b3be$26859070$7390b150$@parsun.com> Message-ID: <55938662.6030708@nethinks.com> > I'm not sure what you mean from dummy-LIRs but I think you mean the ones > that just set up to get a single /22 to transfer it, am I right? If yes, Yup > It cannot keep "dummy-LIRs" from being set up, it just make it less > attractive. exactly! > > But > > My argument was not about "dummy-LIRs set up", I'm talking about the LIRs > that are not new and are already registered years ago, (before RIPE NCC > starts distribution of last /8, before 2012) now if they apply to receive > their last /22 why they have to wait for 2 years to be able to transfer them > to others. (that makes IP distribution more difficult) Personally, I don't think any LIR that already has an allocation in the range of /19 or larger should even be allowed to get a /22 from the last /8 ... considering the trouble new LIRs have to get around with just a single /22, why shouldn't existing companies be stuck with what they have and think about conserving IPs a bit more? Also, if you e.g. already have a /16 (65k addresses), how much good do an additional 1024 addresses do you? Except maybe to monetize them by selling them off to someone who wants them ... So, in summary, keeping the restrictions on the /22 transfers up for both new and existing LIRs is more than fair ... -garry From petr at fast-telecom.net Wed Jul 1 09:46:07 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Wed, 01 Jul 2015 10:46:07 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <5593979F.9010300@resilans.se> References: <5593979F.9010300@resilans.se> Message-ID: <1695861435736767@web7j.yandex.ru> If this proposal closes multi LIR accounts hole, I will support it. But I can't do it now. 01.07.2015, 10:42, "Bengt G?rd?n" : > Den 2015-07-01 08:31, Shahin Gharghi skrev: >> ?Dear Garry >> ?If you read my previous messages you can find my solution. > > It's sort of difficult to follow your previous thoughts due to the lack > of your ability to keep same discussion in same thread. Please, don't > break the threads. > > -- > > Bengt G?rd?n > Resilans AB --? Kind regards, Petr Umelov From gert at space.net Wed Jul 1 10:02:45 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:02:45 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <001f01d0b393$df624c30$9e26e490$@parsun.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> Message-ID: <20150701080245.GR67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 10:21:21AM +1000, Arash Naderpour wrote: > I oppose policy 2015-01 because it can affect LIRs which are not new but > they recently have received their /22 from last /8. (For example an LIR > which is registered in 2010 and just received its /22) > the LIR is not established to just receive the /22 but it has to wait for 2 > years to be able to transfer it and I don't see any reason for this > limitation. As a side effect it makes it harder for IP distribution which is > the main goal of RIPE. This is not a new argument. It has been brought up, addressed, and indeed, this is one of the actual *goals* of the policy: stop LIRs from trading away /22s right away. I can see that those LIRs planning to trade off their /22 as soon as possible will not like the policy change, but I think we'll have to live with that (totally unexpected) side effect. (Besides, the main goal of RIPE is not "enable people to sell /22s" but "ensure that the remaining scraps of IPv4 address space are distributed in a way that is as fairly as possible, given the inherent unfairness of a run-out situation") Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Wed Jul 1 10:04:29 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:04:29 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1695861435736767@web7j.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> Message-ID: <20150701080429.GS67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 10:46:07AM +0300, Petr Umelov wrote: > If this proposal closes multi LIR accounts hole, I will support it. But I can't do it now. The argument "this proposal does not go far enough and loopholes remain in other areas" has been heard and is considered addressed. If you want a change that addresses people opening multiple LIRs, please bring up a policy proposal to that extent. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From petr at fast-telecom.net Wed Jul 1 10:19:51 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Wed, 01 Jul 2015 11:19:51 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701080429.GS67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> Message-ID: <2226701435738791@web18h.yandex.ru> If you go here https://www.ripe.net/participate/policies/proposals/2015-01 you can read next: To put this into perspective, the RIPE NCC has allocated about 6,100 /22s from 185/8. In the past six months, the average rate has been around 245 allocations per month. Therefore, the transfers which the policy proposal tries to discourage constitute about 10% of the total allocations in recent months. Why do you calculate the part of transfers for last 6 months when /8 is allocated earlier and the part of transfer for HOLE /8 is only 3%? You also could review the period when the part of transfers was the same as the part of allocated blocks and write that the part of transfers from /8 is 100% 01.07.2015, 11:04, "Gert Doering" : > Hi, > > On Wed, Jul 01, 2015 at 10:46:07AM +0300, Petr Umelov wrote: >> ?If this proposal closes multi LIR accounts hole, I will support it. But I can't do it now. > > The argument "this proposal does not go far enough and loopholes remain > in other areas" has been heard and is considered addressed. > > If you want a change that addresses people opening multiple LIRs, please > bring up a policy proposal to that extent. > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --? Kind regards, Petr Umelov From gert at space.net Wed Jul 1 10:31:06 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:31:06 +0200 Subject: [address-policy-wg] Call to Order (was: Opposing policy 2015-01) In-Reply-To: <559382D2.9090608@nethinks.com> References: <559382D2.9090608@nethinks.com> Message-ID: <20150701083106.GU67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 08:04:02AM +0200, Garry Glendown wrote: > On 01.07.2015 07:38, Shahin Gharghi wrote: > > I agree with Arash and also people can transfer their IP's after two > > years. So the proposal doesn't help again. > > So, in essence, you would rather do NOTHING than accept the proposal, > which at least - at the moment - significantly increases cost for > IP-traders, [..] Garry, please stop argueing points that have already been addressed - it is not necessary to discuss them in detail again and again, Shahin can just as well go back to the list archives and read up on the previous discussion. I see that you intend well, but if your counterparts do not listen it is not serving a useful purpose. General call to order: the noise on the list is again raising quite a lot, by repetition of points that have been discussed (in variants) exhaustively in the discussion and review phases. Last Call is for *new* concerns. If you're not sure if your concern has already been mentioned, don't "just run out and shout", read up the archives first, and Sander's very detailed summary. If you're still not sure, talk to the chairs first (apwg-chairs at ripe.net). What we are NOT interested in is new variants of "this is not going far enough", "people will find other ways to make money", "I want the last /8 policy to be changed in other ways!", "it impacts my business!", "IPv4 must run out quickly, otherwise nobody will deply IPv6!" - these have been heard before. If you keep posting such, we *will* install some sort of moderation to keep the list useful. Most likely just moderating specific individuals. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe at opteamax.de Wed Jul 1 10:32:30 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 01 Jul 2015 10:32:30 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <2226701435738791@web18h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> Message-ID: Hey Guys, why not drop whole "last /8 policy" and give the rest of IPV4 to the first one asking for it? I'd need those IPs, so I am the first one asking. As soon as there are no IPs in last /8 left, this proposal is obsolete. Sorry could not resist! Jens Am 1. Juli 2015 10:19:51 MESZ, schrieb Petr Umelov : >If you go here >https://www.ripe.net/participate/policies/proposals/2015-01 >you can read next: > >To put this into perspective, the RIPE NCC has allocated about 6,100 >/22s from 185/8. In the past six months, the average rate has been >around 245 allocations per month. Therefore, the transfers which the >policy proposal tries to discourage constitute about 10% of the total >allocations in recent months. > >Why do you calculate the part of transfers for last 6 months when /8 is >allocated earlier and the part of transfer for HOLE /8 is only 3%? > >You also could review the period when the part of transfers was the >same as the part of allocated blocks and write that the part of >transfers from /8 is 100% > >01.07.2015, 11:04, "Gert Doering" : >> Hi, >> >> On Wed, Jul 01, 2015 at 10:46:07AM +0300, Petr Umelov wrote: >>> ?If this proposal closes multi LIR accounts hole, I will support it. >But I can't do it now. >> >> The argument "this proposal does not go far enough and loopholes >remain >> in other areas" has been heard and is considered addressed. >> >> If you want a change that addresses people opening multiple LIRs, >please >> bring up a policy proposal to that extent. >> >> Gert Doering >> ????????-- APWG chair >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > >--? >Kind regards, >Petr Umelov > > >!DSPAM:637,5593a3ec280481407632425! Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Wed Jul 1 10:33:55 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:33:55 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <2226701435738791@web18h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> Message-ID: <20150701083355.GV67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 11:19:51AM +0300, Petr Umelov wrote: > If you go here https://www.ripe.net/participate/policies/proposals/2015-01 > you can read next: > > To put this into perspective, the RIPE NCC has allocated about 6,100 /22s from 185/8. In the past six months, the average rate has been around 245 allocations per month. Therefore, the transfers which the policy proposal tries to discourage constitute about 10% of the total allocations in recent months. > > Why do you calculate the part of transfers for last 6 months when /8 is allocated earlier and the part of transfer for HOLE /8 is only 3%? Because, as has been demonstrated to you, this trend has a clear upward curve - and the absolute numbers do not really matter if specific behaviour is seen that the community does not want. Your attempt to argue with the small numbers seen so far has been made in the review phase, and didn't have the desired effect then. So, it is not a *new* argument. So, please stop now, or you WILL be moderated. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From vladimir at quick-soft.net Wed Jul 1 10:42:39 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 11:42:39 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701083355.GV67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> Message-ID: <1997861435740159@web4o.yandex.ru> I already wrote about such "trend". Why did you consider such "trend" as season rising or something else? So I consider "10%" just to make "necessary picture" and this number is not representative. P.S. You can block anybody in this list if you don't like the true. I think it's completely clear to all people what is happening here. 01.07.2015, 11:34, "Gert Doering" : > Hi, > > On Wed, Jul 01, 2015 at 11:19:51AM +0300, Petr Umelov wrote: >> ?If you go here https://www.ripe.net/participate/policies/proposals/2015-01 >> ?you can read next: >> >> ?To put this into perspective, the RIPE NCC has allocated about 6,100 /22s from 185/8. In the past six months, the average rate has been around 245 allocations per month. Therefore, the transfers which the policy proposal tries to discourage constitute about 10% of the total allocations in recent months. >> >> ?Why do you calculate the part of transfers for last 6 months when /8 is allocated earlier and the part of transfer for HOLE /8 is only 3%? > > Because, as has been demonstrated to you, this trend has a clear upward > curve - and the absolute numbers do not really matter if specific behaviour > is seen that the community does not want. > > Your attempt to argue with the small numbers seen so far has been made > in the review phase, and didn't have the desired effect then. So, it is > not a *new* argument. > > So, please stop now, or you WILL be moderated. > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Wed Jul 1 10:46:26 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 11:46:26 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1997861435740159@web4o.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> Message-ID: <2022641435740386@web4o.yandex.ru> * didn't consider such 01.07.2015, 11:42, "Vladimir Andreev" : > I already wrote about such "trend". > > Why did you consider such "trend" as season rising or something else? > > So I consider "10%" just to make "necessary picture" and this number is not representative. > > P.S. You can block anybody in this list if you don't like the true. I think it's completely clear to all people what is happening here. > > 01.07.2015, 11:34, "Gert Doering" : >> ?Hi, >> >> ?On Wed, Jul 01, 2015 at 11:19:51AM +0300, Petr Umelov wrote: >>> ??If you go here https://www.ripe.net/participate/policies/proposals/2015-01 >>> ??you can read next: >>> >>> ??To put this into perspective, the RIPE NCC has allocated about 6,100 /22s from 185/8. In the past six months, the average rate has been around 245 allocations per month. Therefore, the transfers which the policy proposal tries to discourage constitute about 10% of the total allocations in recent months. >>> >>> ??Why do you calculate the part of transfers for last 6 months when /8 is allocated earlier and the part of transfer for HOLE /8 is only 3%? >> >> ?Because, as has been demonstrated to you, this trend has a clear upward >> ?curve - and the absolute numbers do not really matter if specific behaviour >> ?is seen that the community does not want. >> >> ?Your attempt to argue with the small numbers seen so far has been made >> ?in the review phase, and didn't have the desired effect then. So, it is >> ?not a *new* argument. >> >> ?So, please stop now, or you WILL be moderated. >> >> ?Gert Doering >> ?????????-- APWG chair >> ?-- >> ?have you enabled IPv6 on something today...? >> >> ?SpaceNet AG Vorstand: Sebastian v. Bomhard >> ?Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> ?D-80807 Muenchen HRB: 136055 (AG Muenchen) >> ?Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From poty at iiat.ru Wed Jul 1 10:51:36 2015 From: poty at iiat.ru (poty at iiat.ru) Date: Wed, 1 Jul 2015 08:51:36 +0000 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <001f01d0b393$df624c30$9e26e490$@parsun.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> Message-ID: <38A326B32984534586F211FB04239BF855F389B1@Win2008R2.office.iiat> Am I wrong, but the /22 for the existing companies is still subject to "need analysis"? Sort to say - if you have enough IPs in your existing netblock you are not eligible to get this add-ons? Then why the LIR should transfer the IPs if in the process of getting them it shows the need? RIPE NCC is for distributing addresses - it's OK - but for USAGE, not for SELLING. Second consideration is about supposed limitation in distribution of the IP addresses. Am I wrong again, but initially LIR is not the same as ISP? Yes, I agree that often it is the same company, but if an ISP is so badly in need of IPs it can buy SERVICE from a external LIR (the LIR will allow to use a block of its IP addresses). Transfers are not the only way of helping an ISP with addresses. Regards, Vladislav Potapov -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Arash Naderpour Sent: Wednesday, July 1, 2015 3:21 AM To: address-policy-wg at ripe.net Subject: [address-policy-wg] Opposing policy 2015-01 Hi, I oppose policy 2015-01 because it can affect LIRs which are not new but they recently have received their /22 from last /8. (For example an LIR which is registered in 2010 and just received its /22) the LIR is not established to just receive the /22 but it has to wait for 2 years to be able to transfer it and I don't see any reason for this limitation. As a side effect it makes it harder for IP distribution which is the main goal of RIPE. Regards, Arash Naderpour From gert at space.net Wed Jul 1 10:55:21 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:55:21 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1997861435740159@web4o.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> Message-ID: <20150701085521.GW67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 11:42:39AM +0300, Vladimir Andreev wrote: > P.S. You can block anybody in this list if you don't like the true. I think it's completely clear to all people what is happening here. Indeed. A few individuals try to stop the proposal by sabotaging the mailing list and our consensus-based process. And it is VERY clear who the individuals are, that they obviously stand to loose some business, and we all understand that you do not like that (but the purpose of the policy proposal *is* to make that business less lucrative, so, yes, we officially do not care for your business). As the chairs cannot let individuals destroy this list, moderation will happen if you just go on and on and on. We have received enough complaints about the noise level already. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From shahin at gharghi.ir Wed Jul 1 10:56:48 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Wed, 1 Jul 2015 01:56:48 -0700 Subject: [address-policy-wg] We need IPv4 transfers Message-ID: Dear Garry So after accepting this policy people can transfer IP's without any additional cost like before. It means although you know this policy won't work you are supporting it? Why??! -- Shahin Gharghi From gert at space.net Wed Jul 1 10:59:26 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 10:59:26 +0200 Subject: [address-policy-wg] We need IPv4 transfers In-Reply-To: References: Message-ID: <20150701085926.GX67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 01:56:48AM -0700, Shahin Gharghi wrote: > So after accepting this policy people can transfer IP's without any > additional cost like before. > It means although you know this policy won't work you are supporting it? Why??! Please take this into private conversation. Gert Doering -- AWPG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From aleksbulgakov at gmail.com Wed Jul 1 11:04:59 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 1 Jul 2015 12:04:59 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701085521.GW67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> Message-ID: Whatever we say, you made the decision, and our opinion does not matter. Right? If anybody supports this proposal *and write +1* his voice will be counted, if don't he should write many arguments. May be someone doesn't like this text but this is the trooth. 2015-07-01 11:55 GMT+03:00 Gert Doering : > Hi, > > On Wed, Jul 01, 2015 at 11:42:39AM +0300, Vladimir Andreev wrote: >> P.S. You can block anybody in this list if you don't like the true. I think it's completely clear to all people what is happening here. > > Indeed. A few individuals try to stop the proposal by sabotaging the > mailing list and our consensus-based process. > > And it is VERY clear who the individuals are, that they obviously stand > to loose some business, and we all understand that you do not like that > (but the purpose of the policy proposal *is* to make that business less > lucrative, so, yes, we officially do not care for your business). > > > As the chairs cannot let individuals destroy this list, moderation will > happen if you just go on and on and on. We have received enough complaints > about the noise level already. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From gert at space.net Wed Jul 1 11:10:26 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 11:10:26 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> Message-ID: <20150701091026.GY67883@Space.Net> hi, On Wed, Jul 01, 2015 at 12:04:59PM +0300, Aleksey Bulgakov wrote: > Whatever we say, you made the decision, and our opinion does not matter. > Right? > > If anybody supports this proposal *and write +1* his voice will be > counted, if don't he should write many arguments. > > May be someone doesn't like this text but this is the trooth. Please read up how the policy development process in the RIPE region works. We're in Last Call now, which means "any arguments that have been brought up and addressed in discussion and review phase are no longer interesting" (because we consider them to be addressed, and per Sander's summary, have reached rough consensus even if not everybody agrees). The Last Call phase is specifically there to bring up *new* arguments that have been overlooked before. Whether *I* agree with you or anyone else has nothing to do with how the PDP works - if the argument is not new, it is not interesting, and just noise on the list. If people insist on creating noise, they will be quietened. (Note that I'm also totally not interested in "support!" statements in this phase) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From vladimir at quick-soft.net Wed Jul 1 11:19:48 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 12:19:48 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701085521.GW67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> Message-ID: <2234611435742388@web4o.yandex.ru> I'm NOT speaking about my business now and you see it. I'm speaking about current proposal discussion and ask you why were not some really IMPORTANT facts taken into consideration? And I tell personally you again: I just want opinion of all parties involved into discussion would considered equally. P.S. Block me if you want. It's THE last method then someone have no more arguments and can't solve a problem in a normal way. 01.07.2015, 11:55, "Gert Doering" : > Hi, > > On Wed, Jul 01, 2015 at 11:42:39AM +0300, Vladimir Andreev wrote: >> ?P.S. You can block anybody in this list if you don't like the true. I think it's completely clear to all people what is happening here. > > Indeed. A few individuals try to stop the proposal by sabotaging the > mailing list and our consensus-based process. > > And it is VERY clear who the individuals are, that they obviously stand > to loose some business, and we all understand that you do not like that > (but the purpose of the policy proposal *is* to make that business less > lucrative, so, yes, we officially do not care for your business). > > As the chairs cannot let individuals destroy this list, moderation will > happen if you just go on and on and on. We have received enough complaints > about the noise level already. > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Wed Jul 1 11:21:20 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 12:21:20 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701091026.GY67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> Message-ID: <2243891435742480@web4o.yandex.ru> Please don't tell about Last Call. In Review you also didn't considered point of view which differs from you own. 01.07.2015, 12:10, "Gert Doering" : > hi, > > On Wed, Jul 01, 2015 at 12:04:59PM +0300, Aleksey Bulgakov wrote: >> ?Whatever we say, you made the decision, and our opinion does not matter. >> ?Right? >> >> ?If anybody supports this proposal *and write +1* his voice will be >> ?counted, if don't he should write many arguments. >> >> ?May be someone doesn't like this text but this is the trooth. > > Please read up how the policy development process in the RIPE region works. > > We're in Last Call now, which means "any arguments that have been brought > up and addressed in discussion and review phase are no longer interesting" > (because we consider them to be addressed, and per Sander's summary, have > reached rough consensus even if not everybody agrees). > > The Last Call phase is specifically there to bring up *new* arguments > that have been overlooked before. > > Whether *I* agree with you or anyone else has nothing to do with how the > PDP works - if the argument is not new, it is not interesting, and just > noise on the list. If people insist on creating noise, they will be > quietened. > > (Note that I'm also totally not interested in "support!" statements in > this phase) > > Gert Doering > ????????-- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From jim at rfc1035.com Wed Jul 1 11:24:23 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 1 Jul 2015 10:24:23 +0100 Subject: [address-policy-wg] A failure to communicate In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> Message-ID: On 1 Jul 2015, at 10:04, Aleksey Bulgakov wrote: > Whatever we say, you made the decision, and our opinion does not matter. > Right? No, no and no. The WG made (or is making) the decision in the usual manner: by consensus. The WG's co-chairs are responsible for determining when the WG has reached consensus. The opinion of every member of the WG matters and is taken into account in that consensus determination. Provided of course the WG member expresses their opinion and does so in a reasonable way (ie no abusive/insulting language or ad-hominem attacks). Consensus does not mean that everyone has to agree. Please read RFC7282. Here's a quote from that: "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated". Although this RFC is for the IETF's decision making its principles apply to RIPE and other Internet organisations too. In the case of 2015-01, we're at the point where the WG needs to decide if all the issues in the proposal have been addressed even if some of them not have not been accommodated. IMO we have reached that point. YMMV. From aleksbulgakov at gmail.com Wed Jul 1 11:27:05 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 1 Jul 2015 12:27:05 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <2243891435742480@web4o.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <2243891435742480@web4o.yandex.ru> Message-ID: In discussion phase and review period we wrote e.g. 1+1=2 and didn't think the WG can write that it is false and then write big letter that 1+1 = 10 (in binary system) and the Last Call period take place. So we try to write again but this was said earlier and doesn't counted now. 2015-07-01 12:21 GMT+03:00 Vladimir Andreev : > Please don't tell about Last Call. > > In Review you also didn't considered point of view which differs from you own. > > 01.07.2015, 12:10, "Gert Doering" : >> hi, >> >> On Wed, Jul 01, 2015 at 12:04:59PM +0300, Aleksey Bulgakov wrote: >>> Whatever we say, you made the decision, and our opinion does not matter. >>> Right? >>> >>> If anybody supports this proposal *and write +1* his voice will be >>> counted, if don't he should write many arguments. >>> >>> May be someone doesn't like this text but this is the trooth. >> >> Please read up how the policy development process in the RIPE region works. >> >> We're in Last Call now, which means "any arguments that have been brought >> up and addressed in discussion and review phase are no longer interesting" >> (because we consider them to be addressed, and per Sander's summary, have >> reached rough consensus even if not everybody agrees). >> >> The Last Call phase is specifically there to bring up *new* arguments >> that have been overlooked before. >> >> Whether *I* agree with you or anyone else has nothing to do with how the >> PDP works - if the argument is not new, it is not interesting, and just >> noise on the list. If people insist on creating noise, they will be >> quietened. >> >> (Note that I'm also totally not interested in "support!" statements in >> this phase) >> >> Gert Doering >> -- APWG chair >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 -- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29 From shahin at gharghi.ir Wed Jul 1 11:31:10 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Wed, 1 Jul 2015 02:31:10 -0700 Subject: [address-policy-wg] We need IPv4 transfers Message-ID: Dear Gert This question is for you and all of the members too. There is nothing private. -- Shahin Gharghi From vladimir at quick-soft.net Wed Jul 1 11:39:38 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 12:39:38 +0300 Subject: [address-policy-wg] A failure to communicate In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> Message-ID: <2894191435743578@web20g.yandex.ru> Hi! Yes. Also RFC7282 says: > One hundred people for and five people against might not be rough consensus > > Section 3 discussed the idea of consensus being achieved when objections had been addressed (that is, properly considered, and accommodated if necessary). > Because of this, using rough consensus avoids a major pitfall of a straight vote: If there is a minority of folks who have a valid technical objection, that objection must be dealt with before consensus can be declared. And I already spoke that important aspects were not considered! So do we have real consensus? 01.07.2015, 12:25, "Jim Reid" : > On 1 Jul 2015, at 10:04, Aleksey Bulgakov wrote: > >> ?Whatever we say, you made the decision, and our opinion does not matter. >> ?Right? > > No, no and no. The WG made (or is making) the decision in the usual manner: by consensus. The WG's co-chairs are responsible for determining when the WG has reached consensus. The opinion of every member of the WG matters and is taken into account in that consensus determination. Provided of course the WG member expresses their opinion and does so in a reasonable way (ie no abusive/insulting language or ad-hominem attacks). > > Consensus does not mean that everyone has to agree. Please read RFC7282. Here's a quote from that: "Rough consensus is achieved when all issues are addressed, but not necessarily accommodated". Although this RFC is for the IETF's decision making its principles apply to RIPE and other Internet organisations too. > > In the case of 2015-01, we're at the point where the WG needs to decide if all the issues in the proposal have been addressed even if some of them not have not been accommodated. IMO we have reached that point. YMMV. --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From frettled at gmail.com Wed Jul 1 11:46:40 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 1 Jul 2015 11:46:40 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <2243891435742480@web4o.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <2243891435742480@web4o.yandex.ru> Message-ID: On Wed, Jul 1, 2015 at 11:21 AM, Vladimir Andreev wrote: > Please don't tell about Last Call. > > In Review you also didn't considered point of view which differs from you > own. > The point of views you have expressed, HAVE been discussed, and they have been considered previously, by the working group. You are free to feel that they haven't been adequately considered, and that point is adequately made. However, your point of view didn't gain consensus, or even break consensus. At this point in time, it's too late for you to raise the same points again, no matter how much you disagree with how things stand. At this point in time, you may raise NEW concerns. You haven't, though. I see that you feel it's more important to make noise, than to follow the procedures. If you really felt so strongly about this, which I sincerely doubt, you would have started the process with a counter-proposal, annulling the effects of 2015-01. You could have had a new proposal on the table right away, and the PDP could have started, and if your proposal gained consensus, it could have taken effect early next year. But your choice is to make noise instead. This is disrespectful to us other group members. PS: WG chairs, my apologies for posting this, but I really, really felt the need to point out that this isn't just something of Gert's doing. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Wed Jul 1 12:00:19 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 1 Jul 2015 11:00:19 +0100 Subject: [address-policy-wg] A failure to communicate In-Reply-To: <2894191435743578@web20g.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <2894191435743578@web20g.yandex.ru> Message-ID: <49B89353-030E-4941-B233-DAEA56E58AC7@rfc1035.com> On 1 Jul 2015, at 10:39, Vladimir Andreev wrote: > And I already spoke that important aspects were not considered! Please state calmly and clearly what important aspects were not considered. ie On I said and the WG said . IMO the issues I raised in were not considered because . Here's the proof: . IMO the consensus determination of the WG co-chairs is therefore flawed because . Please do not try to revisit previous discussion threads about the proposal. We're past that point. The discussion phase of the PDP is over. We're now at the stage of assessing if the consensus determination is valid or not. If you think that's not valid, please present evidence to support that opinion. That does not mean restating the issues you raised in the discussion phase. We're no longer discussing these in the context of the current proposal. Or shouldn't be doing that now. You are of course welcome to put forward a new policy proposal which reflects your earlier concerns. You can do that irrespective of whether the current proposal gets adopted or not. From jim at rfc1035.com Wed Jul 1 12:09:22 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 1 Jul 2015 11:09:22 +0100 Subject: [address-policy-wg] A failure to communicate In-Reply-To: <2894191435743578@web20g.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <2894191435743578@web20g.yandex.ru> Message-ID: On 1 Jul 2015, at 10:39, Vladimir Andreev wrote: > So do we have real consensus? For this policy proposal, I think we do. Though it's not down to me to make that decision. Jan Ingvoldstat has just explained where you are going wrong and what to do about that. Short version: you're in a hole, so stop digging. Unless you have NEW concerns about 2015-01 that have not been previously raised, I think you should stop adding noise. More noise is unhelpful and annoying and just a total waste of everyone's time. The PDP is open to you if you wish to propose a policy which addresses your concerns and/or cancels 2015-01. From gert at space.net Wed Jul 1 12:48:13 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 12:48:13 +0200 Subject: [address-policy-wg] We need IPv4 transfers In-Reply-To: References: Message-ID: <20150701104813.GB67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 02:31:10AM -0700, Shahin Gharghi wrote: > This question is for you and all of the members too. There is nothing private. You are just adding noise to the list. Please discuss your differing interpretations of the process with Garry off-list - and feel free to come back if you have *new* contributions. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From vladimir at quick-soft.net Wed Jul 1 12:56:19 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 13:56:19 +0300 Subject: [address-policy-wg] A failure to communicate In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <2894191435743578@web20g.yandex.ru> Message-ID: <1046991435748179@web21h.yandex.ru> Ha-ha. > Short version: you're in a hole, so stop digging. As I see the circus must go on. Just to laugh at... 01.07.2015, 13:09, "Jim Reid" : > On 1 Jul 2015, at 10:39, Vladimir Andreev wrote: > >> ?So do we have real consensus? > > For this policy proposal, I think we do. Though it's not down to me to make that decision. > > Jan Ingvoldstat has just explained where you are going wrong and what to do about that. Short version: you're in a hole, so stop digging. > > Unless you have NEW concerns about 2015-01 that have not been previously raised, I think you should stop adding noise. More noise is unhelpful and annoying and just a total waste of everyone's time. > > The PDP is open to you if you wish to propose a policy which addresses your concerns and/or cancels 2015-01. --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Wed Jul 1 13:01:56 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Wed, 01 Jul 2015 14:01:56 +0300 Subject: [address-policy-wg] A failure to communicate In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <2894191435743578@web20g.yandex.ru> Message-ID: <1084561435748516@web21h.yandex.ru> A little addition: "stop adding noise", "stop making noise" ? all these sentence are the best-loved for me :) Of course you and some other people don't make a noise. Just me and people opposing this proposal :) 01.07.2015, 13:09, "Jim Reid" : > On 1 Jul 2015, at 10:39, Vladimir Andreev wrote: > >> ?So do we have real consensus? > > For this policy proposal, I think we do. Though it's not down to me to make that decision. > > Jan Ingvoldstat has just explained where you are going wrong and what to do about that. Short version: you're in a hole, so stop digging. > > Unless you have NEW concerns about 2015-01 that have not been previously raised, I think you should stop adding noise. More noise is unhelpful and annoying and just a total waste of everyone's time. > > The PDP is open to you if you wish to propose a policy which addresses your concerns and/or cancels 2015-01. --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From shahin at gharghi.ir Wed Jul 1 13:13:17 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Wed, 1 Jul 2015 04:13:17 -0700 Subject: [address-policy-wg] We need IPv4 transfers Message-ID: Hi > You are just adding noise to the list. The messages show you are making noise. If you have any idea we can hear that. And I think you'd better play fair. You are using your power as a chair to get this proposal accepted. I asked a question and if you have an answer for that, tell me. People will be able to transfer their /22 after accepting this proposal. So this proposal won't help at all. What's your answer as a person who supports this proposal and of course as the chair? -- Shahin Gharghi From jim at rfc1035.com Wed Jul 1 13:23:39 2015 From: jim at rfc1035.com (Jim Reid) Date: Wed, 1 Jul 2015 12:23:39 +0100 Subject: [address-policy-wg] We need IPv4 transfers In-Reply-To: References: Message-ID: <465F90C9-B2DD-4738-9078-90C21D825B5A@rfc1035.com> On 1 Jul 2015, at 12:13, Shahin Gharghi wrote: > And I think you'd better play fair. You are using your > power as a chair to get this proposal accepted. This is utter nonsense. > I asked a question and if you have an answer for that, tell me. > People will be able to transfer their /22 after accepting this > proposal. So this proposal won't help at all. Yawn. The WG has discussed this at length. The time for that discussion is over. We're past that point in the PDP. The 2015-01 is now at the stage where the consensus determination is scrutinised or for any NEW issues to be raised. You're doing neither and it's not helpful. > What's your answer as a person who supports this proposal and of > course as the chair? These questions are utterly inappropriate to this point of the PDP. If you feel that there are NEW issues which have been overlooked, raise them. Don't re-hash the arguments that were made earlier. If you consider the consensus determination was somehow flawed, please explain how. These are the only options for where we are currently in the PDP for this proposal. Kindly respect that. You are of course welcome to come forward with a new proposal in support of your PoV or to overturn an existing policy. The PDP machinery is open to all. From gert at space.net Wed Jul 1 13:26:57 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Jul 2015 13:26:57 +0200 Subject: [address-policy-wg] A failure to communicate In-Reply-To: <49B89353-030E-4941-B233-DAEA56E58AC7@rfc1035.com> References: <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <2894191435743578@web20g.yandex.ru> <49B89353-030E-4941-B233-DAEA56E58AC7@rfc1035.com> Message-ID: <20150701112657.GD67883@Space.Net> Hi, On Wed, Jul 01, 2015 at 11:00:19AM +0100, Jim Reid wrote: > On 1 Jul 2015, at 10:39, Vladimir Andreev wrote: > > > And I already spoke that important aspects were not considered! > > Please state calmly and clearly what important aspects were not considered. ie > > On I said and the WG said . IMO the issues I raised in were not considered because . Here's the proof: . IMO the consensus determination of the WG co-chairs is therefore flawed because . And please take into account the summary Sander has posted at the end of the discussion phase. Especially for the objections (where it was possible to understand the point made, not in all cases that succeeded) Sander has written a detailed answer why he thinks that this is not sufficient to hold up the proposal. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs at radu-adrian.feurdean.net Wed Jul 1 13:33:21 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 01 Jul 2015 13:33:21 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <001001d0b3be$26859070$7390b150$@parsun.com> References: <001f01d0b393$df624c30$9e26e490$@parsun.com> <55936A99.6040409@nethinks.com> <001001d0b3be$26859070$7390b150$@parsun.com> Message-ID: <1435750401.1787011.312447025.0E7CB45C@webmail.messagingengine.com> On Wed, Jul 1, 2015, at 07:23, Arash Naderpour wrote: > My argument was not about "dummy-LIRs set up", I'm talking about the LIRs > that are not new and are already registered years ago, (before RIPE NCC > starts distribution of last /8, before 2012) now if they apply to receive > their last /22 why they have to wait for 2 years to be able to transfer > them to others. (that makes IP distribution more difficult) If by "distributing to others" you mean to customers, nothing stops you from doing that. If by "distributing to others" you mean "transfer" (generally the permanent transfer, which must pass RIPE NCC approval), yes, it does stop you from doing that, and that's the whole point. > It was not mandatory to receive last /22 and they are plenty of LIRs that > are still using their existing allocations without getting their last /22. No impact for them. They are not "obliged" to get their "last /22". > Not every olds LIR received its /22 till now and this 2015-01 can affect them too. > Is it something supposed to be happened? I oppose this proposal > because it has unnecessary effect on some of the genuine LIRs too. Please explain. From ripe-wgs at radu-adrian.feurdean.net Wed Jul 1 13:38:09 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 01 Jul 2015 13:38:09 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1695861435736767@web7j.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> Message-ID: <1435750689.1787885.312451065.32320ECC@webmail.messagingengine.com> On Wed, Jul 1, 2015, at 09:46, Petr Umelov wrote: > If this proposal closes multi LIR accounts hole, I will support it. But I > can't do it now. The multi LIR accounts issue is a pure NCC issue, not a policy one. That discussion should probbaly be started on members-discuss mailing-list where RIPE NCC officials do respond to such issues. From ripe-wgs at radu-adrian.feurdean.net Wed Jul 1 13:39:45 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 01 Jul 2015 13:39:45 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701080429.GS67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> Message-ID: <1435750785.1788095.312452353.57775699@webmail.messagingengine.com> On Wed, Jul 1, 2015, at 10:04, Gert Doering wrote: > If you want a change that addresses people opening multiple LIRs, please > bring up a policy proposal to that extent. ... on members-discuss and possibly for the next GM. That is a membership issue not a policy one. From nick at inex.ie Wed Jul 1 19:03:34 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 1 Jul 2015 18:03:34 +0100 Subject: [address-policy-wg] ARIN reaches depletion Message-ID: <55941D66.2030409@inex.ie> https://www.arin.net/announcements/2015/20150701.html Nick From office at ip4market.ru Wed Jul 1 20:01:49 2015 From: office at ip4market.ru (Staff) Date: Wed, 01 Jul 2015 21:01:49 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150701091026.GY67883@Space.Net> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> Message-ID: <55942B0D.80104@ip4market.ru> Greetings! We discussed internally and divided to write our arguments against 2015-01 again in more clear way: 0) Very interesting discussion, people who see bad things in this proposal write arguments and nobody listen to them, but people who say ok - doesn't say anything. Not fair discussion! 1) This proposal is most profitable for RIPE NCC only and will make end users to get IPs harder (not only from new lirs). 2) It doesn't close multi-LIR ability and that's normal. 3) People who says it's very profitable or so are mistaken. In other case everyone can do that and them also, and they would be against this proposal too, but it's not so as you may see. That's not so. New LIRs ability is open for everyone and people (big IP owners) redistribute IPs more easy. And in most cases it's easy and better then open LIRs. So the fact is that new LIRs registration rate is the same as usual. Rate of LIRs is normal: Year Objects IPs %of /8 Rest Rest ip 2012 779 797696 5% 95% 15979520 2013 1836 1880064 12% 83% 14099456 2014 2469 2534400 16% 67% 11565056 2015 1587 1643520 10% 57% 9921536 Total: 6671 6855680 41% 59% 9921536 +RIPE free IPs pool is growing. total was 627 blocks only from 185.x transfered. but total LIRs that get 185 blocks are and total 6671, its 9,3% it's not significant. 3) The proposal should help market and companies to redistribute IPs from the companies who don't need them to companies who needs them. This proposal is against it. Because it may make more difficult possible transfer = rise the market prices and speculations. We know the real situations on the market and understand what's going on. If heads of this discussions and proposal doesn't listen here we bring that up to the internet to show up in future why does that happen and that statistics shows what we told. 4) As conclusion this proposal doesn't help to switch to IPv6. It only helps to pull a cat by the balls. My conclusion: - This proposal will not help redistributing and transfer IPs. And the main reason for us - it will make other transfers harder (but not new LIRs. Not much people need new lirs or small blocks but ability is good. There is already limitation as block size /22. Yuri at Ip4market On 01.07.2015 12:10, Gert Doering wrote: > hi, > > On Wed, Jul 01, 2015 at 12:04:59PM +0300, Aleksey Bulgakov wrote: >> Whatever we say, you made the decision, and our opinion does not >> matter. Right? >> >> If anybody supports this proposal *and write +1* his voice will >> be counted, if don't he should write many arguments. >> >> May be someone doesn't like this text but this is the trooth. > > Please read up how the policy development process in the RIPE > region works. > > We're in Last Call now, which means "any arguments that have been > brought up and addressed in discussion and review phase are no > longer interesting" (because we consider them to be addressed, and > per Sander's summary, have reached rough consensus even if not > everybody agrees). > > The Last Call phase is specifically there to bring up *new* > arguments that have been overlooked before. > > Whether *I* agree with you or anyone else has nothing to do with > how the PDP works - if the argument is not new, it is not > interesting, and just noise on the list. If people insist on > creating noise, they will be quietened. > > (Note that I'm also totally not interested in "support!" statements > in this phase) > > Gert Doering -- APWG chair > From office at ip4market.ru Wed Jul 1 20:06:09 2015 From: office at ip4market.ru (Staff) Date: Wed, 01 Jul 2015 21:06:09 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <55942B0D.80104@ip4market.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> Message-ID: <55942C11.2030902@ip4market.ru> fix in (3) correct number is 313/6671 is 4.6% On 01.07.2015 21:01, Staff wrote: > Greetings! > > We discussed internally and divided to write our arguments against > 2015-01 again in more clear way: > > 0) Very interesting discussion, people who see bad things in this > proposal write arguments and nobody listen to them, but people who say > ok - doesn't say anything. Not fair discussion! > > 1) This proposal is most profitable for RIPE NCC only and will make end > users to get IPs harder (not only from new lirs). > > 2) It doesn't close multi-LIR ability and that's normal. > > 3) People who says it's very profitable or so are mistaken. In other > case everyone can do that and them also, and they would be against this > proposal too, but it's not so as you may see. That's not so. New LIRs > ability is open for everyone and people (big IP owners) redistribute IPs > more easy. And in most cases it's easy and better then open LIRs. So the > fact is that new LIRs registration rate is the same as usual. > > Rate of LIRs is normal: > > Year Objects IPs %of /8 Rest Rest ip > 2012 779 797696 5% 95% 15979520 > 2013 1836 1880064 12% 83% 14099456 > 2014 2469 2534400 16% 67% 11565056 > 2015 1587 1643520 10% 57% 9921536 > Total: 6671 6855680 41% 59% 9921536 > > +RIPE free IPs pool is growing. > > total was 627 blocks only from 185.x transfered. > but total LIRs that get 185 blocks are and total 6671, its 9,3% > it's not significant. > > 3) The proposal should help market and companies to redistribute IPs > from the companies who don't need them to companies who needs them. > This proposal is against it. Because it may make more difficult possible > transfer = rise the market prices and speculations. We know the real > situations on the market and understand what's going on. > > If heads of this discussions and proposal doesn't listen here we bring > that up to the internet to show up in future why does that happen and > that statistics shows what we told. > > 4) As conclusion this proposal doesn't help to switch to IPv6. It only > helps to pull a cat by the balls. > > My conclusion: > - This proposal will not help redistributing and transfer IPs. And the > main reason for us - it will make other transfers harder (but not new > LIRs. Not much people need new lirs or small blocks but ability is good. > There is already limitation as block size /22. > > Yuri at Ip4market > > > > On 01.07.2015 12:10, Gert Doering wrote: >> hi, >> >> On Wed, Jul 01, 2015 at 12:04:59PM +0300, Aleksey Bulgakov wrote: >>> Whatever we say, you made the decision, and our opinion does not >>> matter. Right? >>> >>> If anybody supports this proposal *and write +1* his voice will >>> be counted, if don't he should write many arguments. >>> >>> May be someone doesn't like this text but this is the trooth. >> >> Please read up how the policy development process in the RIPE >> region works. >> >> We're in Last Call now, which means "any arguments that have been >> brought up and addressed in discussion and review phase are no >> longer interesting" (because we consider them to be addressed, and >> per Sander's summary, have reached rough consensus even if not >> everybody agrees). >> >> The Last Call phase is specifically there to bring up *new* >> arguments that have been overlooked before. >> >> Whether *I* agree with you or anyone else has nothing to do with >> how the PDP works - if the argument is not new, it is not >> interesting, and just noise on the list. If people insist on >> creating noise, they will be quietened. >> >> (Note that I'm also totally not interested in "support!" statements >> in this phase) >> >> Gert Doering -- APWG chair >> > > From swmike at swm.pp.se Thu Jul 2 08:41:34 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 2 Jul 2015 08:41:34 +0200 (CEST) Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <55942B0D.80104@ip4market.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> Message-ID: On Wed, 1 Jul 2015, Staff wrote: > 3) The proposal should help market and companies to redistribute IPs > from the companies who don't need them to companies who needs them. Thanks for writing a more structured list. However, the only thing of interest (to me) right now is to answer the question: "what harm would the proposed policy change do?", especially ones that hasn't been brought up. So please re-write your email with that in mind, and provide clear examples of what _harm_ the policy change would do to the actual companies that are going to USE the space (and their end users), not the ones trading in the address space. -- Mikael Abrahamsson email: swmike at swm.pp.se From st at sct.de Thu Jul 2 18:14:32 2015 From: st at sct.de (Stefan Schiele) Date: Thu, 02 Jul 2015 18:14:32 +0200 Subject: [address-policy-wg] "ALLOCATED UNSPECIFIED" In-Reply-To: <20150630193410.GC78290@ernw.de> References: <20150630193410.GC78290@ernw.de> Message-ID: <55956368.2080706@sct.de> Hi Enno, we are one of those "remnant corner cases" you mentioned. We have a /24 "ASSIGNED PI" that is part of a larger "ALLOCATED UNSPECIFIED" block and we are using this address space for our infrastructure for about 20 years now. Actually, we don't feel any real pain with the status of that address space. The only pitfall is that we can't make any database changes on our own so we have to ask someone else to do the requested changes on our behalf. In our case we had to ask KPN and at any time they were very friendly and helpful and made all the changes we asked for; they even provided RPKI for that address space. Therefore we don't have a real problem with that netblock; although I would prefer to be able to make database changes on our own; and additionally I'm a little bit uncomfortable that someone else is doing all that service for us for free. I think it would be a good idea to prepare a policy for this kind of blocks; and for sure I would be willing to help you in doing so. My first thought was to break up a larger allocation into several sub allocations. However, breaking up e.g. a /16 into several sub allocations due to just a few smaller netblocks within does not sound like the perfect solution to me either (that would have a negative impact to the size of the routing tables). Maybe it would be a solution to work with sub allocations (at least for PA space)? Kind Regards, Stefan Am 30.06.2015 um 21:34 schrieb Enno Rey: > Hi, > > some of you might already cringe just from this mail's subject ;-) > I'm currently involved in handling some netblocks which are in "ALLOCATED UNSPECIFIED" state and this turns out to be surprisingly difficult, even in cases where both organizations (that is the LIR holding the covering aggregate and the organization which received the "more specific" PI assignment back in the 90s) apparently agree on a course of action. My impression is that these difficulties not least arise as seemingly no policy exists on "how to convert those assignments into 'ASSIGNED PI' or 'ALLOCATED PA' space". I'm aware that these netblocks might only be "remnant corner cases" totally irrelevant to the majority of the community. Which brings me to the following questions: > > a) do any of you "feel the same pain" when it comes to these blocks? > b) do you think a policy proposal should be prepared how to handle those? I'm willing to prepare sth. > c) what could such a proposal look like? What do those concerned think how a reasonable way of moving those blocks into a "stable state" can be identified/described. > > many thanks in advance for any type of feedback. > everybody have a pleasant evening > > Enno > > -- SCT Schiele GmbH Am Erlengraben 10 76275 Ettlingen Tel.: +49 7243 / 53 84 0 Fax: +49 7243 / 53 84 20 www.sct.de Sitz der Gesellschaft: Ettlingen Amtsgericht Mannheim HRB 362642 Gesch?ftsf?hrer: Stefan Schiele -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr at fast-telecom.net Sun Jul 5 21:05:27 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sun, 05 Jul 2015 22:05:27 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> Message-ID: <1574631436123127@web21h.yandex.ru> Hi, WG. What will we get if the proposal will take place without some changes. Businesses will buy new blocks by means of M&A. They can find funds from other directions of their business and will be wait for 24 months and make transfer. If we want really to close the hole, we have to make some changes - "The blocks allocated from the RIPE NCC and aren't used during 12 months should be returned to the RIPE NCC pool". Otherwise the last /8 will be exhausted more quickly. So I suggest to return this proposal to discussion phase. 02.07.2015, 09:41, "Mikael Abrahamsson" : > On Wed, 1 Jul 2015, Staff wrote: > >> ?3) The proposal should help market and companies to redistribute IPs >> ?from the companies who don't need them to companies who needs them. > > Thanks for writing a more structured list. > > However, the only thing of interest (to me) right now is to answer the > question: > > "what harm would the proposed policy change do?", especially ones that > hasn't been brought up. > > So please re-write your email with that in mind, and provide clear > examples of what _harm_ the policy change would do to the actual companies > that are going to USE the space (and their end users), not the ones > trading in the address space. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se --? Kind regards, Petr Umelov From randy at psg.com Sun Jul 5 21:26:14 2015 From: randy at psg.com (Randy Bush) Date: Mon, 06 Jul 2015 04:26:14 +0900 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1574631436123127@web21h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> Message-ID: > "The blocks allocated from the RIPE NCC and aren't used during 12 > months should be returned to the RIPE NCC pool". sounds like an interesting proposal. you should write the proposal and submit it, just as we do all new proposals. randy From tom at kebab.org.pl Sun Jul 5 21:40:00 2015 From: tom at kebab.org.pl (Tomasz SLASKI) Date: Sun, 5 Jul 2015 21:40:00 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1574631436123127@web21h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> Message-ID: <55998810.6060309@kebab.org.pl> Hi Petr, and WG W dniu 2015-07-05 o 21:05, Petr Umelov pisze: > If we want really to close the hole, we have to make some changes - "The blocks allocated from the RIPE NCC and aren't used during 12 months should be returned to the RIPE NCC pool". In my opinion this does not help to close the disputed hole. It's very simple (technically) to demonstrate, that the allocated pool is in use. -- Tomasz ?l?ski tom at kebab.org.pl From jim at rfc1035.com Mon Jul 6 00:44:34 2015 From: jim at rfc1035.com (Jim Reid) Date: Sun, 5 Jul 2015 23:44:34 +0100 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1574631436123127@web21h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> Message-ID: <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> On 5 Jul 2015, at 20:05, Petr Umelov wrote: > > So I suggest to return this proposal to discussion phase. That?s not how it?s done. The discussion phase for the proposal is OVER. The WG has just about reached consensus. At this stage of the PDP (Last Call) we assess whether that consensus determination is valid or not. Last Call also gives everyone a final chance to raise NEW issues which did not get attention during the proposal?s discussion phase. If there are new issues, please go ahead and raise them. Your latest message seems to be going over the same old ground. If you are doing that, don?t. It's inappropriate and unhelpful. [And just a waste of everyone?s time too.] Please stop posting more of the same stuff that the WG has heard. The WG has addressed those concerns already. If there is something substantive to your latest posting apart from that earlier discussion, please state clearly what those new issue(s) are and explain how/why they were not addressed during the discussion phase. You?ve certainly not done that yet. Nobody?s found any fault with the summary of the proposal discussion that Sander posted a couple of weeks ago. I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. From shahin at gharghi.ir Mon Jul 6 14:48:10 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Mon, 6 Jul 2015 17:18:10 +0430 Subject: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9 In-Reply-To: References: Message-ID: Hi > I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. > The problem is: The person who should justify the criticisms, never does! And he is supporting the proposal so that he will never return it to the discussion phase... -- Shahin Gharghi From frettled at gmail.com Mon Jul 6 18:25:24 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 6 Jul 2015 18:25:24 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9 In-Reply-To: References: Message-ID: On Mon, Jul 6, 2015 at 2:48 PM, Shahin Gharghi wrote: > Hi > > > I would be happy to support returning this proposal to the discussion > phase, but only if there are compelling reasons to do so. To date nobody > has made the case for taking that action. Although some have asked for > this, nobody has put forward anything to justify these requests. The case > has not been made yet. It?s up to you and your fellow travellers to make > that case. > > > > The problem is: The person who should justify the criticisms, never > does! And he is > supporting the proposal so that he will never return it to the > discussion phase... > I'm not quite sure what you're trying to say here. I completely agree that the person(s) who should justify the criticisms, never do(es). One of those persons is *you*. There are no other persons, than the ones who voice the criticism itself, who need to justify that criticism. I, or any other WG member, or WG chair, are in no way obliged to write your justification for you. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkennedy at libertyglobal.com Tue Jul 7 14:31:05 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 7 Jul 2015 12:31:05 +0000 Subject: [address-policy-wg] PA policy Message-ID: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> Hello, At the risk of sounding na?ve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to. "LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7 To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation. Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR? Regards, James From nick at inex.ie Tue Jul 7 14:55:32 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 7 Jul 2015 13:55:32 +0100 Subject: [address-policy-wg] PA policy In-Reply-To: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <559BCC44.6000600@inex.ie> On 07/07/2015 13:31, Kennedy, James wrote: > At the risk of sounding na?ve, I have a question regarding the > legitimate usage of PA address space. That is, what *type* of network or > End User can it be assigned to. > > "LIRs are allocated Provider Aggregatable (PA) address space. They > sub-allocate and assign this to *downstream networks*." > https://www.ripe.net/publications/docs/ripe-643#7 > > To me this reads networks or End Users assigned PA space must receive > transit from the LIR holding the parent allocation. > > Or can the LIR assign PA blocks to customers/companies that don't > receive transit, or any other technical network service for that matter, > from the LIR? There are two separate things going on here. 1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted. 2. if an end user receives a PA block from LIR1 and then attempts to route it out through a different network who operates LIR2, that's an issue for the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not the routing police and has no policy basis to intervene. Situation #2 is relatively common and becoming more so. >From an end user point of view, it's a pretty damned stupid thing to do because if the end user terminates their business relationship with LIR1, then they terminate any rights to use the address space they received from LIR1. This puts the them in the situation where their business continuity depends on a contractual relationship with a single supplier. Not clever. >From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away. >From the point of view of LIR2, this often ends up causing problems between them, the end user and LIR1. Nick From d.baeza at tvt-datos.es Tue Jul 7 14:59:25 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Tue, 07 Jul 2015 14:59:25 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <559BCC44.6000600@inex.ie> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <559BCC44.6000600@inex.ie> Message-ID: <559BCD2D.7070500@tvt-datos.es> I thing he understand "end user" as a residential customer user. But a residential customer user is not recieving the PA space, is the ISP of the customer who recieve it. LIR is not ISP. You can be a LIR and not an ISP and vice versa. El 07/07/2015 a las 14:55, Nick Hilliard escribi?: > On 07/07/2015 13:31, Kennedy, James wrote: >> At the risk of sounding na?ve, I have a question regarding the >> legitimate usage of PA address space. That is, what *type* of network or >> End User can it be assigned to. >> >> "LIRs are allocated Provider Aggregatable (PA) address space. They >> sub-allocate and assign this to *downstream networks*." >> https://www.ripe.net/publications/docs/ripe-643#7 >> >> To me this reads networks or End Users assigned PA space must receive >> transit from the LIR holding the parent allocation. >> >> Or can the LIR assign PA blocks to customers/companies that don't >> receive transit, or any other technical network service for that matter, >> from the LIR? > > There are two separate things going on here. > > 1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was > accepted. > > 2. if an end user receives a PA block from LIR1 and then attempts to route > it out through a different network who operates LIR2, that's an issue for > the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not the routing > police and has no policy basis to intervene. > > Situation #2 is relatively common and becoming more so. > > From an end user point of view, it's a pretty damned stupid thing to do > because if the end user terminates their business relationship with LIR1, > then they terminate any rights to use the address space they received from > LIR1. This puts the them in the situation where their business continuity > depends on a contractual relationship with a single supplier. Not clever. > > From the point of view of LIR1, some LIRs run with this as a business model > in order to prevent customers moving away. > > From the point of view of LIR2, this often ends up causing problems between > them, the end user and LIR1. > > Nick > From gert at space.net Tue Jul 7 16:18:02 2015 From: gert at space.net (Gert Doering) Date: Tue, 7 Jul 2015 16:18:02 +0200 Subject: [address-policy-wg] 2015-02 end of review phase / consensus reached (Keep IPv6 PI When Requesting IPv6 Allocation) In-Reply-To: References: Message-ID: <20150707141802.GA66794@Space.Net> Dear AP WG, On Mon, Jun 08, 2015 at 03:43:14PM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2015-02, "Keep IPv6 PI > When Requesting IPv6 Allocation" has been published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 7 July 2015. The review phase is now over. I'm not exactly overwhelmed by the number of supporting voices we saw from the community - barely 21 statements of support, as compared to 30 statements of support in the first days of the discussion phase!! Of course I am just joking :-) - this proposal received more voices of support than any other proposal before, *and* no single objection, so judging consensus is so easy that I'm too lazy to write up the "who said what?" summary, and just declare consensus instead. Formally: So, I declare we have consensus, and move 2015-02 to Last Call. Marco will send the formal announcement for that in the next days. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From tore at fud.no Tue Jul 7 16:40:50 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 7 Jul 2015 16:40:50 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <20150707164050.75e99a7c@envy.fud.no> Hi James, * Kennedy, James > "LIRs are allocated Provider Aggregatable (PA) address space. They > sub-allocate and assign this to *downstream networks*." > https://www.ripe.net/publications/docs/ripe-643#7 > > To me this reads networks or End Users assigned PA space must receive > transit from the LIR holding the parent allocation. I understand "downstream" to refer to the hierarchical internet number registry system here, not BGP routing topology. Otherwise, we'd all have to buy our IP-transit from the RIPE NCC, who'd in turn have to buy it from the IANA.... > Or can the LIR assign PA blocks to customers/companies that don't > receive transit, or any other technical network service for that > matter, from the LIR? That's how the policy has been implemented so far, yes. Note that the RIPE database gladly allow ASSIGNED PA inet(6)nums to get their own completely independent route(6) objects. Tore From jkennedy at libertyglobal.com Tue Jul 7 17:08:25 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 7 Jul 2015 15:08:25 +0000 Subject: [address-policy-wg] PA policy In-Reply-To: <559BCD2D.7070500@tvt-datos.es> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <559BCC44.6000600@inex.ie> <559BCD2D.7070500@tvt-datos.es> Message-ID: <13E63C78A6256E4A857726374FBF926E127D81FE@NLAMSPEXMB022.upcit.ds.upc.biz> Hi Nick, El 07/07/2015 a las 14:55, Nick Hilliard escribi?: > 1. LIRs can assign PA blocks for any reason at all since policy 2013-03 was accepted. Well, the policy specifically states PA is to be sub-allocated or assigned to *downstream networks* of the LIR. https://www.ripe.net/publications/docs/ripe-643#7 Doesn't this mean transit via the allocation holding LIR's network is a requirement? PI (though no longer distributed) space was/is for LIR independent routing, not PA. > From the point of view of LIR1, some LIRs run with this as a business model in order to prevent customers moving away. Not only to prevent customers moving away, but also to attain mountains of IPv4 PA allocations from the NCC (albeit before RIPE depletion) that are autonomous to the LIR's network - if the LIR even has a network! Daniel, Not talking about residential end users. Focusing on LIRs that assigns a PA block to a company from their allocation, but doesn't actually provide any service to that company. Is this breaking the aforementioned policy statement? Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Daniel Baeza (Red y Sistemas TVT) Sent: 07 July 2015 14:59 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PA policy I thing he understand "end user" as a residential customer user. But a residential customer user is not recieving the PA space, is the ISP of the customer who recieve it. LIR is not ISP. You can be a LIR and not an ISP and vice versa. El 07/07/2015 a las 14:55, Nick Hilliard escribi?: > On 07/07/2015 13:31, Kennedy, James wrote: >> At the risk of sounding na?ve, I have a question regarding the >> legitimate usage of PA address space. That is, what *type* of network >> or End User can it be assigned to. >> >> "LIRs are allocated Provider Aggregatable (PA) address space. They >> sub-allocate and assign this to *downstream networks*." >> https://www.ripe.net/publications/docs/ripe-643#7 >> >> To me this reads networks or End Users assigned PA space must receive >> transit from the LIR holding the parent allocation. >> >> Or can the LIR assign PA blocks to customers/companies that don't >> receive transit, or any other technical network service for that >> matter, from the LIR? > > There are two separate things going on here. > > 1. LIRs can assign PA blocks for any reason at all since policy > 2013-03 was accepted. > > 2. if an end user receives a PA block from LIR1 and then attempts to > route it out through a different network who operates LIR2, that's an > issue for the end user, LIR1 and LIR2 to resolve. The RIPE NCC is not > the routing police and has no policy basis to intervene. > > Situation #2 is relatively common and becoming more so. > > From an end user point of view, it's a pretty damned stupid thing to > do because if the end user terminates their business relationship with > LIR1, then they terminate any rights to use the address space they > received from LIR1. This puts the them in the situation where their > business continuity depends on a contractual relationship with a single supplier. Not clever. > > From the point of view of LIR1, some LIRs run with this as a business > model in order to prevent customers moving away. > > From the point of view of LIR2, this often ends up causing problems > between them, the end user and LIR1. > > Nick > From jkennedy at libertyglobal.com Tue Jul 7 18:17:23 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 7 Jul 2015 16:17:23 +0000 Subject: [address-policy-wg] PA policy In-Reply-To: <20150707164050.75e99a7c@envy.fud.no> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707164050.75e99a7c@envy.fud.no> Message-ID: <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> Hi Tore, True. If indeed the "downstream" in this policy statement is in relation to the hierarchical registry system rather than in BGP transit terms, then yes PA customer assignments that are routed separately to the LIR are valid. I raised the question as I've heard several community members complain, validly IMO, about some LIRs that have accumulated vast v4 PA allocations that are technically autonomous to the LIR. Seems strange to have been allowed, especially considering the market value on these resources now. James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 07 July 2015 16:41 To: Kennedy, James Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PA policy Hi James, * Kennedy, James > "LIRs are allocated Provider Aggregatable (PA) address space. They > sub-allocate and assign this to *downstream networks*." > https://www.ripe.net/publications/docs/ripe-643#7 > > To me this reads networks or End Users assigned PA space must receive > transit from the LIR holding the parent allocation. I understand "downstream" to refer to the hierarchical internet number registry system here, not BGP routing topology. Otherwise, we'd all have to buy our IP-transit from the RIPE NCC, who'd in turn have to buy it from the IANA.... > Or can the LIR assign PA blocks to customers/companies that don't > receive transit, or any other technical network service for that > matter, from the LIR? That's how the policy has been implemented so far, yes. Note that the RIPE database gladly allow ASSIGNED PA inet(6)nums to get their own completely independent route(6) objects. Tore From apwg at c4inet.net Tue Jul 7 18:34:09 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 7 Jul 2015 17:34:09 +0100 Subject: [address-policy-wg] PA policy In-Reply-To: <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707164050.75e99a7c@envy.fud.no> <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <20150707163409.GA93095@cilantro.c4inet.net> On Tue, Jul 07, 2015 at 04:17:23PM +0000, Kennedy, James wrote: >True. If indeed the "downstream" in this policy statement is in >relation to the hierarchical registry system rather than in BGP >transit terms, then yes PA customer assignments that are routed >separately to the LIR are valid. Actually, even assignments which are *not at all* connected to the Internet are valid. In practice, the vast majority of assignments will be downstream of the assigning LIR due to the routing issues mentioned earlier in the thread. >I raised the question as I've heard several community members >complain, validly IMO, about some LIRs that have accumulated >vast v4 PA allocations that are technically autonomous to the >LIR. Seems strange to have been allowed, especially considering >the market value on these resources now. It is allowed because the intention of the policy was never to impose a hierarchy on the structure of the Internet, merely to have a distributed registry, rather than one huge juggernaut. And yeah, the phrasing is sufficiently ambiguous for this to have come up on the list before... rgds, Sascha Luck From tore at fud.no Tue Jul 7 19:27:12 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 7 Jul 2015 19:27:12 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707164050.75e99a7c@envy.fud.no> <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <20150707192712.5592f586@envy.fud.no> * Kennedy, James > I raised the question as I've heard several community members > complain, validly IMO, about some LIRs that have accumulated vast v4 > PA allocations that are technically autonomous to the LIR. Seems > strange to have been allowed, especially considering the market value > on these resources now. Consider the following use case: A government (national, regional, local - doesn't matter) sets up an LIR in order to provide addresses to its various branches, offices, schools, whatever. The goverment doesn't run an ISP of their own (they probably used to run a telco at some point, but that was privatised), so the LIR does not provide any connectivity to anyone - so that's up to the branches, offices, schools to put out public tenders for and obtain from a local or national ISP. The reason for having the government LIR in the first place, is to prevent the use of ISP-owned addresses and the lock-in effect that results in (on the local level, the techies might not be knowledgeable enough to avoid that from the beginning, and certainly asking every school to run their own LIR would be a non-starter). Finally, having the entire government in one (or a few) nicely aggregated block gives significant technical benefits. The government LIR might also charge a fee to its downstream clients, just to aid a little with garbage collection and ensure the LIR hostmaster(s) get paid. Or mentally replace "government" with some kind of large and distributed enterprise or group of companies. The umbrella corporation could provide LIR services to a number of sub-companies. That's a valid use-case we'd like to make sure is allowed, agreed? And it has been been allowed since before I got involved in this WG at least. However, if you look at it, it's not very easy to distinguish between my example government LIR and the "IP leasing LIR" you think it's strange that has been allowed. Technically, they're doing exactly the same thing. So both are allowed. Anyway. The vultures will fight over IPv4's carcass. That's natural, and unavoidable - just let them. I for one am glad that this community hasn't succumbed to the temptation to create more and more draconian and restrictive policies, all in the name of wringing some extra short term life span out of IPv4. Had we done so, I believe we'd be causing ourselves more long term damage than short term benefit - such policies would inevitably get in the way of regular folks running their business in a regular way, the (participating member of) RIPE community and its policies end up losing legitimacy for the larger community we're supposed to serve. Tore From he at uninett.no Tue Jul 7 20:10:20 2015 From: he at uninett.no (Havard Eidnes) Date: Tue, 07 Jul 2015 20:10:20 +0200 (CEST) Subject: [address-policy-wg] PA policy In-Reply-To: <20150707192712.5592f586@envy.fud.no> References: <20150707164050.75e99a7c@envy.fud.no> <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707192712.5592f586@envy.fud.no> Message-ID: <20150707.201020.15426879.he@uninett.no> > * Kennedy, James > >> I raised the question as I've heard several community members >> complain, validly IMO, about some LIRs that have accumulated vast v4 >> PA allocations that are technically autonomous to the LIR. Seems >> strange to have been allowed, especially considering the market value >> on these resources now. The allocation of large PA blocks from the ancient (or not so ancient) past is what one might call "water under the bridge". What's done in this area is done, and can not easily be undone. With that said: If I've understood correctly, the "P" in "PA" (and "PI") is meant to be more or less synonymous with ISP, not with a provider of LIR services only. This was so that the ISP could announce the whole covering address space as a single route, thereby reducing the amount of entropy we collectively have to carry on our backs as ISPs. If the ISP / PA block holder insists, and you as a customer and current sub-PA-block holder wish to cancel the service with the ISP, the ISP can insist that you cease using the PA addresses you were assigned as a customer. The converse is not true: if the PA-holding LIR lets you take your sub-block with you, they can allow it, and I beleive that's what you said as well, Tore. I'm not sure that is the typical case, though(?) Your example with a government or large organization which holds one or more large PA block and which out of administrative convenience ("renumbering is so hard, even if I just have client hosts!") or for other reasons doles out address blocks to widely distributed sub- organizations, and where each sub-organization is free to choose its own ISP to use will result in injection of more entropy into the global routing system, as each individual sub-organization's route will need to be carried globally, and there's no possibility for route aggregation. I'm hesitating a little to find an appropriate characterization of what would happen if such pratices became very widespread, but I'm sure it certainly isn't positive for the sustainability of the network. Regretfully, noone has come up with any sort of economic (the only one which works...) dis-incentive countering such behaviour, so we'll end up by muddling along. BTW, this argument is address-family independent... Regards, - H?vard From apwg at c4inet.net Tue Jul 7 20:36:42 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 7 Jul 2015 19:36:42 +0100 Subject: [address-policy-wg] PA policy In-Reply-To: <20150707.201020.15426879.he@uninett.no> References: <20150707164050.75e99a7c@envy.fud.no> <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> Message-ID: <20150707183642.GB93095@cilantro.c4inet.net> On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote: >global routing system, as each individual sub-organization's route >will need to be carried globally, and there's no possibility for >route aggregation. I'm hesitating a little to find an appropriate >characterization of what would happen if such pratices became very >widespread, but I'm sure it certainly isn't positive for the >sustainability of the network. > >Regretfully, noone has come up with any sort of economic (the only >one which works...) dis-incentive countering such behaviour, so >we'll end up by muddling along. In the context of global IPv4 expiration, RIPE policy can't prevent de-aggregation down to /24 (or longer) any more than King Knut was able to order the tide back out. >BTW, this argument is address-family independent... ripe-641 strongly discourages ipv6 de-aggregation (and there is no good argument for it either) but the sheer potential size of the routing table will become a problem at some stage. That will have to be solved eventually but that is not likely to be on this ML.. ;) rgds, Sascha Luck From he at uninett.no Tue Jul 7 21:06:00 2015 From: he at uninett.no (Havard Eidnes) Date: Tue, 07 Jul 2015 21:06:00 +0200 (CEST) Subject: [address-policy-wg] PA policy In-Reply-To: <20150707183642.GB93095@cilantro.c4inet.net> References: <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> <20150707183642.GB93095@cilantro.c4inet.net> Message-ID: <20150707.210600.261977723.he@uninett.no> > On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote: >>global routing system, as each individual sub-organization's route >>will need to be carried globally, and there's no possibility for >>route aggregation. I'm hesitating a little to find an appropriate >>characterization of what would happen if such pratices became very >>widespread, but I'm sure it certainly isn't positive for the >>sustainability of the network. >> >>Regretfully, noone has come up with any sort of economic (the only >>one which works...) dis-incentive countering such behaviour, so >>we'll end up by muddling along. > > In the context of global IPv4 expiration, RIPE policy can't > prevent de-aggregation down to /24 (or longer) any more than King > Knut was able to order the tide back out. I know, but the perspective needed to be put forward. >>BTW, this argument is address-family independent... > > ripe-641 strongly discourages ipv6 de-aggregation (and there is no > good argument for it either) but the sheer potential size of the > routing table will become a problem at some stage. That will have to > be solved eventually but that is not likely to be > on this ML.. ;) Yup. Regards, - H?vard From tore at fud.no Tue Jul 7 21:40:12 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 7 Jul 2015 21:40:12 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <20150707.201020.15426879.he@uninett.no> References: <20150707164050.75e99a7c@envy.fud.no> <13E63C78A6256E4A857726374FBF926E127D8231@NLAMSPEXMB022.upcit.ds.upc.biz> <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> Message-ID: <20150707214012.2ca9012d@envy.fud.no> * Havard Eidnes > If I've understood correctly, the "P" in "PA" (and "PI") is meant to > be more or less synonymous with ISP, not with a provider of LIR > services only. This was so that the ISP could announce the whole > covering address space as a single route, thereby reducing the > amount of entropy we collectively have to carry on our backs as > ISPs. If the ISP / PA block holder insists, and you as a customer > and current sub-PA-block holder wish to cancel the service with the > ISP, the ISP can insist that you cease using the PA addresses you > were assigned as a customer. > > The converse is not true: if the PA-holding LIR lets you take your > sub-block with you, they can allow it, and I beleive that's what you > said as well, Tore. I'm not sure that is the typical case, though(?) It's not the common case, no. Usually, ISP = LIR. But even though it might be a corner case, it's still a case we do (and should) cater for. > Your example with a government or large organization which holds one > or more large PA block and which out of administrative convenience > ("renumbering is so hard, even if I just have client hosts!") or for > other reasons doles out address blocks to widely distributed sub- > organizations, and where each sub-organization is free to choose its > own ISP to use will result in injection of more entropy into the > global routing system, as each individual sub-organization's route > will need to be carried globally, and there's no possibility for > route aggregation. I'm hesitating a little to find an appropriate > characterization of what would happen if such pratices became very > widespread, but I'm sure it certainly isn't positive for the > sustainability of the network. > > Regretfully, noone has come up with any sort of economic (the only > one which works...) dis-incentive countering such behaviour, so > we'll end up by muddling along. > > BTW, this argument is address-family independent... Indeed. But, the reason why such non-ISP LIRs might become more prevalent nowadays is IPv4 depletion. We already know that IPv4 isn't going to be sustainable though, so I don't think it is anything we need to worry about or attempt to "fix" or "prevent" through implementing restrictive policies. In the longer term, in the IPv6 world, such non-ISP LIRs will again be just a corner case that exists in limited numbers, and probably only where there's actually a good reason for doing it that way. Allowing for them to exist thus won't cause significant harm to the routing table. (Also keep in mind that the preferred alternative for many of them would be to use IPv6 PI instead, which would be worse as a bunch of PI blocks cannot be re-aggregated at a later point in time.) Tore From jkennedy at libertyglobal.com Tue Jul 7 22:22:15 2015 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 7 Jul 2015 20:22:15 +0000 Subject: [address-policy-wg] PA policy In-Reply-To: <20150707.210600.261977723.he@uninett.no> References: <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> <20150707183642.GB93095@cilantro.c4inet.net> <20150707.210600.261977723.he@uninett.no> Message-ID: <13E63C78A6256E4A857726374FBF926E127D82EF@NLAMSPEXMB022.upcit.ds.upc.biz> * Tore Anderson Totally appreciate and agree with the government use case, or other such orgs with multiple dispersed branches or end sites needing their own ISP connectivity, especially for orgs that are not an ISP. But these are all of the one entity, or legal affiliates within an umbrella company. Unfortunately policy that rightfully allowed these also permitted some opportunistic rogue LIRs to receive copious v4 space for End User networks that were/are completely unrelated to the LIR but for the subletting of internet number resources. I know of such LIRs now forcing unsuspecting long-term assignment End Users to return the space in order for the LIR to sell the parent allocation. While it was for these End User network requirements that the NCC originally approved the IPv4 resources to the LIR in the first place! Very ugly. End user's fault for not requesting PI or becoming an LIR, I know. Still ugly. Regarding aggregation Vs multiple routing entries for allocation usage efficiently, well it's a bit late for that argument. Nice King Knut reference Sascha ;) Btw fear not, the goal of this thread wasn't to initiate strict policy proposal to regurgitate potentially misused v4 allocations. That ship has sailed, RIPE depleted years ago. Important such topical discussions be aired though, as I know many out there have questions these days. Regards, James -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Havard Eidnes Sent: 07 July 2015 21:06 To: apwg at c4inet.net Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] PA policy > On Tue, Jul 07, 2015 at 08:10:20PM +0200, Havard Eidnes wrote: >>global routing system, as each individual sub-organization's route >>will need to be carried globally, and there's no possibility for route >>aggregation. I'm hesitating a little to find an appropriate >>characterization of what would happen if such pratices became very >>widespread, but I'm sure it certainly isn't positive for the >>sustainability of the network. >> >>Regretfully, noone has come up with any sort of economic (the only one >>which works...) dis-incentive countering such behaviour, so we'll end >>up by muddling along. > > In the context of global IPv4 expiration, RIPE policy can't prevent > de-aggregation down to /24 (or longer) any more than King Knut was > able to order the tide back out. I know, but the perspective needed to be put forward. >>BTW, this argument is address-family independent... > > ripe-641 strongly discourages ipv6 de-aggregation (and there is no > good argument for it either) but the sheer potential size of the > routing table will become a problem at some stage. That will have to > be solved eventually but that is not likely to be on this ML.. ;) Yup. Regards, - H?vard From ripe-wgs at radu-adrian.feurdean.net Tue Jul 7 22:36:02 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Tue, 07 Jul 2015 22:36:02 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <13E63C78A6256E4A857726374FBF926E127D82EF@NLAMSPEXMB022.upcit.ds.upc.biz> References: <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> <20150707183642.GB93095@cilantro.c4inet.net> <20150707.210600.261977723.he@uninett.no> <13E63C78A6256E4A857726374FBF926E127D82EF@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: <1436301362.1289543.317702065.41066293@webmail.messagingengine.com> On Tue, Jul 7, 2015, at 22:22, Kennedy, James wrote: > Unfortunately policy that rightfully allowed these also permitted some > opportunistic rogue LIRs to receive copious v4 space for End User > networks that were/are completely unrelated to the LIR but for the > subletting of internet number resources. For at least 10 years, some of those companies played the unofficial role of "national internet registries", with pricing better adapted to the local economical situation. > I know of such LIRs now forcing unsuspecting long-term assignment End > Users to return the space in order for the LIR to sell the parent "Take the money and run". They played the NIR, but they were just private companies offering a service in exchange of money. Please note however that at least 2 such LIRs have heavily fragmented their allocations before kicking out users. > End user's fault for not requesting PI or becoming an LIR, I know. Still ugly. We agree, some of those users don't. Not everybody in RIPE region is RIPE NCC-friendly. Even among LIRs, some just consider RIPE NCC as a regular commercial services supplier. -- R-A.F. From he at uninett.no Tue Jul 7 23:52:51 2015 From: he at uninett.no (Havard Eidnes) Date: Tue, 07 Jul 2015 23:52:51 +0200 (CEST) Subject: [address-policy-wg] PA policy In-Reply-To: <20150707214012.2ca9012d@envy.fud.no> References: <20150707192712.5592f586@envy.fud.no> <20150707.201020.15426879.he@uninett.no> <20150707214012.2ca9012d@envy.fud.no> Message-ID: <20150707.235251.447711919.he@uninett.no> >> Regretfully, noone has come up with any sort of economic (the only >> one which works...) dis-incentive countering such behaviour, so >> we'll end up by muddling along. >> >> BTW, this argument is address-family independent... > > Indeed. But, the reason why such non-ISP LIRs might become more > prevalent nowadays is IPv4 depletion. We already know that IPv4 isn't > going to be sustainable though, so I don't think it is anything we need > to worry about or attempt to "fix" or "prevent" through implementing > restrictive policies. True, but that doesn't mean that everyone needs to think this is just A-OK. I'm doing my bit by frowning my nose and muttering here (for all the good that will do). > In the longer term, in the IPv6 world, such non-ISP LIRs will again be > just a corner case that exists in limited numbers, and probably only > where there's actually a good reason for doing it that way. Allowing > for them to exist thus won't cause significant harm to the routing > table. Maybe for the IPv6 allocations, yes, but at present IPv4 and IPv6 is served by the same network infrastructure, so whatever silliness happens in the IPv4 world will affect the infrastructure we use for IPv6 as well. (Yes, that's another argument than what I started with above.) Regards, - H?vard From mschmidt at ripe.net Wed Jul 8 11:10:56 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 08 Jul 2015 11:10:56 +0200 Subject: [address-policy-wg] 2015-02 Last Call for Comments (Keep IPv6 PI When Requesting IPv6 Allocation) Message-ID: Dear colleagues, The proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 6 August 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 6 August 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC From woeber at cc.univie.ac.at Wed Jul 8 12:00:39 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 08 Jul 2015 12:00:39 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <559BCD2D.7070500@tvt-datos.es> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <559BCC44.6000600@inex.ie> <559BCD2D.7070500@tvt-datos.es> Message-ID: <559CF4C7.3050507@cc.univie.ac.at> Just for the benefit of those having come to the Internet Scene a tad later than I did ;-) and having the facts written down: On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: [...] > But a residential customer user is not recieving the PA space, > [it] is the ISP of the customer who recieve it. Even that is not necessarily true: a residential customer can have a (small?) network and receive an assignment from the ISP's PA block. Incidentally, I am one of those examples :-) FWIW, Wilfried From d.baeza at tvt-datos.es Wed Jul 8 12:07:43 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 08 Jul 2015 12:07:43 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <559CF4C7.3050507@cc.univie.ac.at> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <559BCC44.6000600@inex.ie> <559BCD2D.7070500@tvt-datos.es> <559CF4C7.3050507@cc.univie.ac.at> Message-ID: <559CF66F.9000809@tvt-datos.es> Hi Wilfried, I think your case is not usual, as a residential customer usually recieve only 1 IP address (By DHCP or Static) but not a prefix. Of course, Im always talking about IPv4. IPv6 is another thing. How you recieve the prefix? BGP, OSPF, Static Route...?? Im just curious. Regards, El 08/07/2015 a las 12:00, Wilfried Woeber escribi?: > > Just for the benefit of those having come to the Internet Scene > a tad later than I did ;-) and having the facts written down: > > On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: > [...] >> But a residential customer user is not recieving the PA space, >> [it] is the ISP of the customer who recieve it. > > Even that is not necessarily true: a residential customer can > have a (small?) network and receive an assignment from the ISP's > PA block. > > Incidentally, I am one of those examples :-) > > FWIW, > Wilfried > > From woeber at cc.univie.ac.at Wed Jul 8 12:25:02 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 08 Jul 2015 12:25:02 +0200 Subject: [address-policy-wg] PA policy In-Reply-To: <559CF66F.9000809@tvt-datos.es> References: <13E63C78A6256E4A857726374FBF926E127D8101@NLAMSPEXMB022.upcit.ds.upc.biz> <559BCC44.6000600@inex.ie> <559BCD2D.7070500@tvt-datos.es> <559CF4C7.3050507@cc.univie.ac.at> <559CF66F.9000809@tvt-datos.es> Message-ID: <559CFA7E.5020801@cc.univie.ac.at> Hi Daniel! On 2015-07-08 12:07, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi Wilfried, > > I think your case is not usual, as a residential customer usually recieve > only 1 IP address (By DHCP or Static) but not a prefix. Sure, the majority of "residential customers" (definition?) receive just 1 v4 address (and have to live with the mess of NAT), and sometimes even different ones when they disconnect/reconnect. But there are quite a few products out there, offered by ISPs which do understand and respect the needs of customers for more than 1 IPv4 address (and ask for more money ;-) ) > Of course, Im always talking about IPv4. Same here :-) > IPv6 is another thing. Yes... > How you recieve the prefix? BGP, OSPF, Static Route...?? Im just curious. Statically configured in my CPE and aggregated by ISP. DHCP internally by CPE (a small router, owned and managed by the ISP) Wilfried > Regards, > > > El 08/07/2015 a las 12:00, Wilfried Woeber escribi?: >> >> Just for the benefit of those having come to the Internet Scene >> a tad later than I did ;-) and having the facts written down: >> >> On 2015-07-07 14:59, Daniel Baeza (Red y Sistemas TVT) wrote: >> [...] >>> But a residential customer user is not recieving the PA space, >>> [it] is the ISP of the customer who recieve it. >> >> Even that is not necessarily true: a residential customer can >> have a (small?) network and receive an assignment from the ISP's >> PA block. >> >> Incidentally, I am one of those examples :-) >> >> FWIW, >> Wilfried >> >> > From mschmidt at ripe.net Thu Jul 9 14:19:35 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 09 Jul 2015 14:19:35 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC From Mathew.Newton643 at official.mod.uk Thu Jul 9 18:18:36 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Thu, 9 Jul 2015 16:18:36 +0000 Subject: [address-policy-wg] [policy-announce] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Hi Marco, > -----Original Message----- > From: policy-announce [mailto:policy-announce-bounces at ripe.net] On > Behalf Of Marco Schmidt > Sent: 09 July 2015 13:20 > The draft document for version 2.0 of the policy proposal 2015-03, > "Assessment Criteria for IPv6 Initial Allocation Size", has now been > published, along with an impact analysis conducted by the RIPE NCC. Thank you to you and colleagues for this. It can't have been the easiest analysis to undertake, not least given the multiple aspects to consider. It is clear however that a great deal of thought and consideration has gone into it. I need to take some time to fully consider all of the detail however my initial view of the interpretation and proposed implementation is very positive. Could I possibly seek some clarification on the following sentence from the second-to-last paragraph of Section A? 'Each assignment will be taken into account only once towards the total count of needed IPv6 space for an organisation and will not be multiplied by the times it is encapsulated in higher addressing plan levels.' Whilst I don't have a specific concern, and it may well be an insignificant statement, I thought it worthwhile double-checking what this means? Regards, Mathew From mschmidt at ripe.net Fri Jul 10 14:14:46 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 10 Jul 2015 14:14:46 +0200 Subject: [address-policy-wg] [policy-announce] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <559FB736.8030003@ripe.net> Hi Matthew, Thanks for your question - it's good to be able to clarify. If the proposal is accepted, we would base our evaluation of IPv6 requests on the number of actual end sites. An LIR could then document its need for addresses according to a range of criteria such as longevity, security requirements for an end site, or the need for aggregation in the hierarchy level of that end site and higher levels in the network topology. This is what is meant by encapsulation of the assignment. An end site cannot be repeated in another part of the addressing plan to qualify again under the same assessment criteria -- this would be a multiplication of the same assignment. So, for example, it would be possible to request extra address space for security and above hierarchy for the same end site, but it would not be possible to mention the same end site again in another part of the addressing plan to request a further reservation for security and hierarchy. I hope this helps. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC On 09/07/15 18:18, Mathew Newton wrote: > Hi Marco, > >> -----Original Message----- >> From: policy-announce [mailto:policy-announce-bounces at ripe.net] On >> Behalf Of Marco Schmidt >> Sent: 09 July 2015 13:20 >> The draft document for version 2.0 of the policy proposal 2015-03, >> "Assessment Criteria for IPv6 Initial Allocation Size", has now been >> published, along with an impact analysis conducted by the RIPE NCC. > Thank you to you and colleagues for this. It can't have been the easiest analysis to undertake, not least given the multiple aspects to consider. It is clear however that a great deal of thought and consideration has gone into it. > > I need to take some time to fully consider all of the detail however my initial view of the interpretation and proposed implementation is very positive. > > Could I possibly seek some clarification on the following sentence from the second-to-last paragraph of Section A? > > 'Each assignment will be taken into account only once towards the total count of needed IPv6 space for an organisation and will not be multiplied by the times it is encapsulated in higher addressing plan levels.' > > Whilst I don't have a specific concern, and it may well be an insignificant statement, I thought it worthwhile double-checking what this means? > > Regards, > > Mathew > > > From tore at fud.no Fri Jul 10 14:44:09 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 10 Jul 2015 14:44:09 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150710144409.6e127352@envy.fud.no> * Marco Schmidt > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-03 I'm generally positive to this proposal, but the impact analysis made me realise that it only applies to *initial* allocations. That causes the new allocation criteria to only benefit any late adopters who do not currently hold an IPv6 allocation. They will get an unfair advantage that the early adopters who are currently holding a [presumably too small] allocation, as the early adopters cannot re-apply for a appropriately sized block under the new allocation criteria. I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold an IPv6 /29 allocation each...so assuming the proposal was intended to help scratch an itch of their own, so to speak, perhaps this is simply an omission? Tore From Mathew.Newton643 at official.mod.uk Fri Jul 10 15:48:43 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Fri, 10 Jul 2015 13:48:43 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150710144409.6e127352@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> Message-ID: Hi Tore, > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Tore Anderson > I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold > an IPv6 /29 allocation each...so assuming the proposal was intended to > help scratch an itch of their own, so to speak, perhaps this is > simply an omission? It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria. Regards, Mathew From sander at steffann.nl Fri Jul 10 16:12:19 2015 From: sander at steffann.nl (Sander Steffann) Date: Fri, 10 Jul 2015 16:12:19 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150710144409.6e127352@envy.fud.no> Message-ID: <17C5CD58-E4FF-4575-975F-27A1C22E169C@steffann.nl> Hi Mathew, >> I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold >> an IPv6 /29 allocation each...so assuming the proposal was intended to >> help scratch an itch of their own, so to speak, perhaps this is >> simply an omission? > > It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria. That is correct. If you return your allocation you can then do a new first-allocation request. With the current text it won't be possible to grow an existing allocation though, as that would use the rules for additional allocations. Cheers, Sander From tore at fud.no Fri Jul 10 19:02:43 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 10 Jul 2015 19:02:43 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150710144409.6e127352@envy.fud.no> Message-ID: <20150710190243.356f6bc8@envy.fud.no> * Mathew Newton > It was our (uk.mod's) expectation/assumption that it would be > possible to return an existing allocation (in an 'unused/as-new' > state) and apply for another under the new criteria. Hi Matthew, If your /29 remains unused I suppose I was wrong to consider you an early adopter of IPv6... ;-) I'm thinking more of an organisation that, e.g., received an /29 (as that was what the policy permitted at the time) and actually started using it as best they could. After the passage of 2015-03 they'd like to get a /28-or-larger under the new allocation criteria, but un-deploying what they currently have in production in order to do so might not be operationally feasible. Their situation is then very similar to the one that 2015-02 ?Keep IPv6 PI When Requesting IPv6 Allocation? sought to fix. Just to be clear, I'm not objecting to the proposal as it currently stands; I just thought the case was worth while mentioning. If you'd rather let whomever ends up in that situation to also be the one to fix it (through a 2015-02-ish proposal), then that's fair enough as far as I'm concerned. Tore From ripe at opteamax.de Fri Jul 10 19:19:56 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Fri, 10 Jul 2015 19:19:56 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150710190243.356f6bc8@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> Message-ID: <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> Hi, as far as I am informed each V6- allocation made by RIPE had always a "reserved" space after the actual allocation which allows "extending" upto /27 ... so returning seems not to be necassary ... at least not as long as /27 is sufficient. BR Jens Am 10. Juli 2015 19:02:43 MESZ, schrieb Tore Anderson : >* Mathew Newton > >> It was our (uk.mod's) expectation/assumption that it would be >> possible to return an existing allocation (in an 'unused/as-new' >> state) and apply for another under the new criteria. > >Hi Matthew, > >If your /29 remains unused I suppose I was wrong to consider you an >early adopter of IPv6... ;-) > >I'm thinking more of an organisation that, e.g., received an /29 (as >that was what the policy permitted at the time) and actually started >using it as best they could. After the passage of 2015-03 they'd like >to get a /28-or-larger under the new allocation criteria, but >un-deploying what they currently have in production in order to do so >might not be operationally feasible. Their situation is then very >similar to the one that 2015-02 ?Keep IPv6 PI When Requesting IPv6 >Allocation? sought to fix. > >Just to be clear, I'm not objecting to the proposal as it currently >stands; I just thought the case was worth while mentioning. If you'd >rather let whomever ends up in that situation to also be the one to fix >it (through a 2015-02-ish proposal), then that's fair enough as far as >I'm concerned. > >Tore > > >!DSPAM:637,559ffad4149491050911710! Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From Mathew.Newton643 at official.mod.uk Fri Jul 10 20:12:09 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Fri, 10 Jul 2015 18:12:09 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150710190243.356f6bc8@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> Message-ID: Hi Tore, > If your /29 remains unused I suppose I was wrong to consider you an > early adopter of IPv6... ;-) 'Early adopter' is a loose term so I won't go there but by 'unused' I was more meaning in an 'able-to-be-reissued' sense i.e. not being present in the Internet routing table, on blacklists etc. :-) > I'm thinking more of an organisation that, e.g., received an /29 (as > that was what the policy permitted at the time) and actually started > using it as best they could. After the passage of 2015-03 they'd like > to get a /28-or-larger under the new allocation criteria, but > un-deploying what they currently have in production in order to do so > might not be operationally feasible. Understood. This policy proposal is indeed not intended to cater for those situations and is focussed only on initial allocations. It might sound selfish however consideration was given to covering subsequent allocations also but it was decided that broadening the scope too much and potentially having to debate HD-ratios etc might be like trying to boil the ocean. > Just to be clear, I'm not objecting to the proposal as it currently > stands; I just thought the case was worth while mentioning. If you'd > rather let whomever ends up in that situation to also be the one to fix > it (through a 2015-02-ish proposal), then that's fair enough as far as > I'm concerned. I'd rather leave subsequent allocations to a separate policy proposal if at all possible, but would certainly support its development (indeed making the proposal if there was no candidate sponsor). I think it stands to reason that any accepted change in criteria for initial allocation sizes ought to be also reflected in consideration of subsequent allocation requests also. Of course, there may be no easy way around the problem of some organisations having 'landlocked' allocations but even then renumbering might be the least-worst option (the alternative being slowly strangled by too small an allocation). Regards, Mathew From tore at fud.no Fri Jul 10 22:11:11 2015 From: tore at fud.no (Tore Anderson) Date: Fri, 10 Jul 2015 22:11:11 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> Message-ID: <20150710221111.372fc85c@envy.fud.no> * Mathew Newton > This policy proposal is indeed not intended to cater for those > situations and is focussed only on initial allocations. It might > sound selfish [...] Not at all. We all scratch our own itches. Been there, done that. :-) In any case, I don't see much of a downside with this proposal. The only thing one could conceivably be concerned about is excessive consumption of IPv6 due to LIRs grabbing larger allocations than they have a need for, but considering that a /29 is way more than enough for almost everyone and that the IA states that ?LIRs would need to provide comprehensive documentation? in order to make use of this policy I don't see why anyone would bother trying to abusing it. On the other hand I would love to see more IPv6 happening in the governments in the region, so if this policy can help make that happen, I'm all for it. So without further ado: +1 Tore From gert at space.net Fri Jul 10 23:07:17 2015 From: gert at space.net (Gert Doering) Date: Fri, 10 Jul 2015 23:07:17 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150710221111.372fc85c@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <20150710221111.372fc85c@envy.fud.no> Message-ID: <20150710210717.GY67883@Space.Net> Hi, On Fri, Jul 10, 2015 at 10:11:11PM +0200, Tore Anderson wrote: > So without further ado: +1 Haha, clear and easy for the chairs to understand :-) (But a useful discussion about additional allocations. I've been listening, and indeed it might be a useful excercise to come back there after we agree on what the initial criteria should be...) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From shahin at gharghi.ir Sat Jul 11 11:10:24 2015 From: shahin at gharghi.ir (Shahin Gharghi) Date: Sat, 11 Jul 2015 13:40:24 +0430 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Hi +1 to 2015-03 proposal. -- Shahin Gharghi From petr at fast-telecom.net Sat Jul 11 19:27:58 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 11 Jul 2015 20:27:58 +0300 Subject: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9 In-Reply-To: References: Message-ID: <670611436635678@web13j.yandex.ru> Hello, WG. I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. However I see many companies began to open multi LIR accounts and receive additional allocations. E.g. netname: NL-PCXCOP-20150707 netname: NL-PCXMAD-20150707 netname: DK-BORNFIBER5-20150709 netname: DK-BORNFIBER9-20150709 netname: ES-RULZ2-20150710 netname: ES-RULZ3-20150710 netname: ES-SUNNY2-20150710 netname: ES-SUNNY3-20150710 Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. Thus IPv4 pool will be exhausted during 1-2 years. I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. 06.07.2015, 15:49, "Shahin Gharghi" : > Hi > >> ?I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. > > The problem is: The person who should justify the criticisms, never > does! And he is > supporting the proposal so that he will never return it to the > discussion phase... > > -- > Shahin Gharghi --? Kind regards, Petr Umelov From petr at fast-telecom.net Sat Jul 11 19:30:16 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 11 Jul 2015 20:30:16 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> Message-ID: <672321436635816@web13j.yandex.ru> Hello, WG. I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. However I see many companies began to open multi LIR accounts and receive additional allocations. E.g. netname: NL-PCXCOP-20150707 netname: NL-PCXMAD-20150707 netname: DK-BORNFIBER5-20150709 netname: DK-BORNFIBER9-20150709 netname: ES-RULZ2-20150710 netname: ES-RULZ3-20150710 netname: ES-SUNNY2-20150710 netname: ES-SUNNY3-20150710 Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. Thus IPv4 pool will be exhausted during 1-2 years. I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. 06.07.2015, 01:44, "Jim Reid" : > On 5 Jul 2015, at 20:05, Petr Umelov wrote: >> ?So I suggest to return this proposal to discussion phase. > > That?s not how it?s done. The discussion phase for the proposal is OVER. The WG has just about reached consensus. At this stage of the PDP (Last Call) we assess whether that consensus determination is valid or not. Last Call also gives everyone a final chance to raise NEW issues which did not get attention during the proposal?s discussion phase. > > If there are new issues, please go ahead and raise them. Your latest message seems to be going over the same old ground. If you are doing that, don?t. It's inappropriate and unhelpful. [And just a waste of everyone?s time too.] Please stop posting more of the same stuff that the WG has heard. The WG has addressed those concerns already. > > If there is something substantive to your latest posting apart from that earlier discussion, please state clearly what those new issue(s) are and explain how/why they were not addressed during the discussion phase. You?ve certainly not done that yet. Nobody?s found any fault with the summary of the proposal discussion that Sander posted a couple of weeks ago. > > I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. --? Kind regards, Petr Umelov From petr at fast-telecom.net Sat Jul 11 19:45:58 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 11 Jul 2015 20:45:58 +0300 Subject: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9 In-Reply-To: <670611436635678@web13j.yandex.ru> References: <670611436635678@web13j.yandex.ru> Message-ID: <3666201436636758@web1j.yandex.ru> Excuse me. Don't this subject 11.07.2015, 20:28, "Petr Umelov" : > Hello, WG. > > I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. > > However I see many companies began to open multi LIR accounts and receive additional allocations. > > E.g. > netname: NL-PCXCOP-20150707 > netname: NL-PCXMAD-20150707 > > netname: DK-BORNFIBER5-20150709 > netname: DK-BORNFIBER9-20150709 > > netname: ES-RULZ2-20150710 > netname: ES-RULZ3-20150710 > > netname: ES-SUNNY2-20150710 > netname: ES-SUNNY3-20150710 > > Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. > > Thus IPv4 pool will be exhausted during 1-2 years. > > I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. > > 06.07.2015, 15:49, "Shahin Gharghi" : >> ?Hi >> >>> ??I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. >> >> ?The problem is: The person who should justify the criticisms, never >> ?does! And he is >> ?supporting the proposal so that he will never return it to the >> ?discussion phase... >> >> ?-- >> ?Shahin Gharghi > > -- > Kind regards, > Petr Umelov --? Kind regards, Petr Umelov From frettled at gmail.com Sat Jul 11 20:39:06 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 11 Jul 2015 20:39:06 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <672321436635816@web13j.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> Message-ID: On Sat, Jul 11, 2015 at 7:30 PM, Petr Umelov wrote: > Hello, WG. > > I understand you will approve this proposal in any case, you have made a > decision in January and should comply with formalities. > > However I see many companies began to open multi LIR accounts and receive > additional allocations. > > E.g. > netname: NL-PCXCOP-20150707 > netname: NL-PCXMAD-20150707 > > netname: DK-BORNFIBER5-20150709 > netname: DK-BORNFIBER9-20150709 > > netname: ES-RULZ2-20150710 > netname: ES-RULZ3-20150710 > > netname: ES-SUNNY2-20150710 > netname: ES-SUNNY3-20150710 > > Traders don't want to lose their profit and will begin to provide services > to help open new accounts for the same company and companies will be do it > by themselves. > > Thus IPv4 pool will be exhausted during 1-2 years. > > I understand the RIPE NCC dislike someone makes profit using RIPE's > resources but we should not make emotional decisions. > Absolutely, and therefore I suggest that since the above appears to be a big problem for you, that you write down a proposal that will handle this particular problem. Most people want to scratch their itch, and if you scratch it by writing a proposal, your itch can, perhaps, be scratched too. But if you don't write that proposal, nothing will happen, and maybe your worst fears will come true, through your own inaction. It's best that those who see a problem, are the ones to attempt addressing it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr at fast-telecom.net Sat Jul 11 20:47:40 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 11 Jul 2015 21:47:40 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> Message-ID: <1803781436640460@web11h.yandex.ru> Don't tell then I did not warn :) When you will come to your senses and will start the multi LIR hole closing during 6 months, IPv4 will be exhausted 11.07.2015, 21:39, "Jan Ingvoldstad" : > On Sat, Jul 11, 2015 at 7:30 PM, Petr Umelov wrote: >> Hello, WG. >> >> I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. >> >> However I see many companies began to open multi LIR accounts and receive additional allocations. >> >> E.g. >> netname: NL-PCXCOP-20150707 >> netname: NL-PCXMAD-20150707 >> >> netname: DK-BORNFIBER5-20150709 >> netname: DK-BORNFIBER9-20150709 >> >> netname: ES-RULZ2-20150710 >> netname: ES-RULZ3-20150710 >> >> netname: ES-SUNNY2-20150710 >> netname: ES-SUNNY3-20150710 >> >> Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. >> >> Thus IPv4 pool will be exhausted during 1-2 years. >> >> I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. > > Absolutely, and therefore I suggest that since the above appears to be a big problem for you, that you write down a proposal that will handle this particular problem. > > Most people want to scratch their itch, and if you scratch it by writing a proposal, your itch can, perhaps, be scratched too. > > But if you don't write that proposal, nothing will happen, and maybe your worst fears will come true, through your own inaction. > > It's best that those who see a problem, are the ones to attempt addressing it. > -- > Jan --? Kind regards, Petr Umelov From vladimir at quick-soft.net Sat Jul 11 20:52:28 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Sat, 11 Jul 2015 21:52:28 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1803781436640460@web11h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> Message-ID: <3332691436640748@web23o.yandex.ru> Current proposal supporters may also need cheap IP's so this hole will not be closed. It's time to spell out that current proposal never had an aim to reduce IPv4 exhaustion. 11.07.2015, 21:47, "Petr Umelov" : > Don't tell then I did not warn :) > > When you will come to your senses and will start the multi LIR hole closing during 6 months, IPv4 will be exhausted > > 11.07.2015, 21:39, "Jan Ingvoldstad" : >> ?On Sat, Jul 11, 2015 at 7:30 PM, Petr Umelov wrote: >>> ?Hello, WG. >>> >>> ?I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. >>> >>> ?However I see many companies began to open multi LIR accounts and receive additional allocations. >>> >>> ?E.g. >>> ?netname: NL-PCXCOP-20150707 >>> ?netname: NL-PCXMAD-20150707 >>> >>> ?netname: DK-BORNFIBER5-20150709 >>> ?netname: DK-BORNFIBER9-20150709 >>> >>> ?netname: ES-RULZ2-20150710 >>> ?netname: ES-RULZ3-20150710 >>> >>> ?netname: ES-SUNNY2-20150710 >>> ?netname: ES-SUNNY3-20150710 >>> >>> ?Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. >>> >>> ?Thus IPv4 pool will be exhausted during 1-2 years. >>> >>> ?I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. >> >> ?Absolutely, and therefore I suggest that since the above appears to be a big problem for you, that you write down a proposal that will handle this particular problem. >> >> ?Most people want to scratch their itch, and if you scratch it by writing a proposal, your itch can, perhaps, be scratched too. >> >> ?But if you don't write that proposal, nothing will happen, and maybe your worst fears will come true, through your own inaction. >> >> ?It's best that those who see a problem, are the ones to attempt addressing it. >> ?-- >> ?Jan > > -- > Kind regards, > Petr Umelov --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From vladimir at quick-soft.net Sat Jul 11 21:06:49 2015 From: vladimir at quick-soft.net (Vladimir Andreev) Date: Sat, 11 Jul 2015 22:06:49 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <3332691436640748@web23o.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <3332691436640748@web23o.yandex.ru> Message-ID: <3343251436641609@web23o.yandex.ru> All these words about IPv4 "exhaustion" and evil "abusers" is just a screen to reach some goals for some group of people. I think all sane people understand it perfectly. We already see some consequences of this proposal even BEFORE its acceptance (as Petr Umelov wrote): request count for IPv4 allocations has grow. 11.07.2015, 21:52, "Vladimir Andreev" : > Current proposal supporters may also need cheap IP's so this hole will not be closed. > > It's time to spell out that current proposal never had an aim to reduce IPv4 exhaustion. > > 11.07.2015, 21:47, "Petr Umelov" : >> ?Don't tell then I did not warn :) >> >> ?When you will come to your senses and will start the multi LIR hole closing during 6 months, IPv4 will be exhausted >> >> ?11.07.2015, 21:39, "Jan Ingvoldstad" : >>> ??On Sat, Jul 11, 2015 at 7:30 PM, Petr Umelov wrote: >>>> ??Hello, WG. >>>> >>>> ??I understand you will approve this proposal in any case, you have made a decision in January and should comply with formalities. >>>> >>>> ??However I see many companies began to open multi LIR accounts and receive additional allocations. >>>> >>>> ??E.g. >>>> ??netname: NL-PCXCOP-20150707 >>>> ??netname: NL-PCXMAD-20150707 >>>> >>>> ??netname: DK-BORNFIBER5-20150709 >>>> ??netname: DK-BORNFIBER9-20150709 >>>> >>>> ??netname: ES-RULZ2-20150710 >>>> ??netname: ES-RULZ3-20150710 >>>> >>>> ??netname: ES-SUNNY2-20150710 >>>> ??netname: ES-SUNNY3-20150710 >>>> >>>> ??Traders don't want to lose their profit and will begin to provide services to help open new accounts for the same company and companies will be do it by themselves. >>>> >>>> ??Thus IPv4 pool will be exhausted during 1-2 years. >>>> >>>> ??I understand the RIPE NCC dislike someone makes profit using RIPE's resources but we should not make emotional decisions. >>> >>> ??Absolutely, and therefore I suggest that since the above appears to be a big problem for you, that you write down a proposal that will handle this particular problem. >>> >>> ??Most people want to scratch their itch, and if you scratch it by writing a proposal, your itch can, perhaps, be scratched too. >>> >>> ??But if you don't write that proposal, nothing will happen, and maybe your worst fears will come true, through your own inaction. >>> >>> ??It's best that those who see a problem, are the ones to attempt addressing it. >>> ??-- >>> ??Jan >> >> ?-- >> ?Kind regards, >> ?Petr Umelov > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 --? With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503 From frettled at gmail.com Sat Jul 11 21:46:45 2015 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 11 Jul 2015 21:46:45 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <1803781436640460@web11h.yandex.ru> References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> Message-ID: On Sat, Jul 11, 2015 at 8:47 PM, Petr Umelov wrote: > Don't tell then I did not warn :) > > When you will come to your senses and will start the multi LIR hole > closing during 6 months, IPv4 will be exhausted > When will you actually DO something, and not just demand that others take action to solve a problem YOU want fixed? I'm starting to think that you're not really bothered by this "hole", and that you want it to stay open, but keep on complaining that OTHERS aren't doing your job. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr at fast-telecom.net Sat Jul 11 21:56:50 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sat, 11 Jul 2015 22:56:50 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <5593979F.9010300@resilans.se> <1695861435736767@web7j.yandex.ru> <20150701080429.GS67883@Space.Net> <2226701435738791@web18h.yandex.ru> <20150701083355.GV67883@Space.Net> <1997861435740159@web4o.yandex.ru> <20150701085521.GW67883@Space.Net> <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> Message-ID: <481871436644610@web25j.yandex.ru> I can create a proposal, closing multi LIR accounts. Even Marco told me he could provide necessary docs. But it will take 6 months before it will be approved according to the PDP. So I ask to stand-by with this proposal, before we close bigger hole. 11.07.2015, 22:46, "Jan Ingvoldstad" : > On Sat, Jul 11, 2015 at 8:47 PM, Petr Umelov wrote: >> Don't tell then I did not warn :) >> >> When you will come to your senses and will start the multi LIR hole closing during 6 months, IPv4 will be exhausted > > When will you actually DO something, and not just demand that others take action to solve a problem YOU want fixed? > > I'm starting to think that you're not really bothered by this "hole", and that you want it to stay open, but keep on complaining that OTHERS aren't doing your job. > -- > Jan --? Kind regards, Petr Umelov From tore at fud.no Sun Jul 12 08:54:38 2015 From: tore at fud.no (Tore Anderson) Date: Sun, 12 Jul 2015 08:54:38 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> Message-ID: <20150712085438.1dd1e832@envy.fud.no> Hi Jens, * Opteamax GmbH > as far as I am informed each V6- allocation made by RIPE had always a > "reserved" space after the actual allocation which allows "extending" > upto /27 ... so returning seems not to be necassary ... at least not > as long as /27 is sufficient. Actually, the reservation is for a /29. That's precisely the reason why the 6RD proposal allowed for extension up to that exact size: ?Legacy /32 allocations were allocated with a /29 of ?reserved for future expansion? space in mind and can very easily be expanded within that /29. As such, a move from /32 to /29 does not impact negatively RIPE NCC, nor will it lead to discrimination among existing allocations. As the reserved space is already present and would not be allocated to anyone else other than the holder of the /32 already allocated, it seems reasonable to go ahead and let LIRs use the full /29 of space if they need it.? -- https://www.ripe.net/participate/policies/proposals/2011-04 In hindsight, it is a bit of a shame they didn't reserve a /28 instead. That way, 2011-04 could have moved the boundary with a full nibble. Oh well. Tore From gert at space.net Sun Jul 12 16:15:45 2015 From: gert at space.net (Gert Doering) Date: Sun, 12 Jul 2015 16:15:45 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <481871436644610@web25j.yandex.ru> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> Message-ID: <20150712141545.GB67883@Space.Net> Hi, On Sat, Jul 11, 2015 at 10:56:50PM +0300, Petr Umelov wrote: > I can create a proposal, closing multi LIR accounts. Even Marco told me he could provide necessary docs. > > But it will take 6 months before it will be approved according to the PDP. > > So I ask to stand-by with this proposal, before we close bigger hole. These are independent aspects of the same larger problem - and you totally fail to give a reason why "not implementing 2015-01" would help discouraging people from opening multiple LIRs *anyway*... Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From petr at fast-telecom.net Sun Jul 12 16:59:12 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sun, 12 Jul 2015 17:59:12 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150712141545.GB67883@Space.Net> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> Message-ID: <339541436713152@web17j.yandex.ru> Because of sellers won't be sell allocations and will consult how to open multiple LIR accounts and their clients will be get more allocations than if they would buy it as transfer from other LIR. And clients will alert their partners and partners their partners and many members will know about this hole and will deplete IPv4 resources. 12.07.2015, 17:15, "Gert Doering" : > Hi, > > On Sat, Jul 11, 2015 at 10:56:50PM +0300, Petr Umelov wrote: >> ?I can create a proposal, closing multi LIR accounts. Even Marco told me he could provide necessary docs. >> >> ?But it will take 6 months before it will be approved according to the PDP. >> >> ?So I ask to stand-by with this proposal, before we close bigger hole. > > These are independent aspects of the same larger problem - and you totally > fail to give a reason why "not implementing 2015-01" would help discouraging > people from opening multiple LIRs *anyway*... > > Gert Doering > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --? Kind regards, Petr Umelov From randy at psg.com Sun Jul 12 18:55:40 2015 From: randy at psg.com (Randy Bush) Date: Sun, 12 Jul 2015 09:55:40 -0700 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <339541436713152@web17j.yandex.ru> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> <339541436713152@web17j.yandex.ru> Message-ID: please submit the first draft of your proposal. then folk can judge if it is useful to delay 2015-01. otherwise it's just cheap talk. randy From richih.mailinglist at gmail.com Sun Jul 12 19:06:41 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sun, 12 Jul 2015 19:06:41 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <20150712141545.GB67883@Space.Net> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> Message-ID: Procedural question: 2015-01 is still on track and this thread is not influencing it in any way, correct? Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr at fast-telecom.net Sun Jul 12 19:12:23 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sun, 12 Jul 2015 20:12:23 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> <339541436713152@web17j.yandex.ru> Message-ID: <474201436721143@web20h.yandex.ru> What do you mean cheap talk? One company can not setup more than one account. Is it enough for you? But when you will understand it, it will be too late. Or the RIPE NCC wants to deplete IPv4 purposely to help to switch to IPv6. I don't see any reasons of this proposal creation. Here are people who can calculate all part of the transfers. But they are lazy and trust for WG. 12.07.2015, 19:55, "Randy Bush" : > please submit the first draft of your proposal. then folk can judge if > it is useful to delay 2015-01. otherwise it's just cheap talk. > > randy --? Kind regards, Petr Umelov From petr at fast-telecom.net Sun Jul 12 19:15:12 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Sun, 12 Jul 2015 20:15:12 +0300 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <474201436721143@web20h.yandex.ru> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> <339541436713152@web17j.yandex.ru> <474201436721143@web20h.yandex.ru> Message-ID: <477381436721312@web20h.yandex.ru> If you want to be cheated, I won't be prevent it :) 12.07.2015, 20:12, "Petr Umelov" : > What do you mean cheap talk? > One company can not setup more than one account. Is it enough for you? > > But when you will understand it, it will be too late. Or the RIPE NCC wants to deplete IPv4 purposely to help to switch to IPv6. > > I don't see any reasons of this proposal creation. Here are people who can calculate all part of the transfers. But they are lazy and trust for WG. > > 12.07.2015, 19:55, "Randy Bush" : >> ?please submit the first draft of your proposal. then folk can judge if >> ?it is useful to delay 2015-01. otherwise it's just cheap talk. >> >> ?randy > > -- > Kind regards, > Petr Umelov --? Kind regards, Petr Umelov From randy at psg.com Sun Jul 12 19:24:59 2015 From: randy at psg.com (Randy Bush) Date: Sun, 12 Jul 2015 10:24:59 -0700 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <474201436721143@web20h.yandex.ru> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> <339541436713152@web17j.yandex.ru> <474201436721143@web20h.yandex.ru> Message-ID: > What do you mean cheap talk? > One company can not setup more than one account. Is it enough for you? no. there is a simple a process (eurocratic though it may be). submit a proposal. it is not that hard. as you said, marco is kind enough to help. fwiw, i, and i assume many others, would love to see a proposal for tightening the leakage. randy From garry at nethinks.com Sun Jul 12 19:28:34 2015 From: garry at nethinks.com (Garry Glendown) Date: Sun, 12 Jul 2015 19:28:34 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: <474201436721143@web20h.yandex.ru> References: <20150701091026.GY67883@Space.Net> <55942B0D.80104@ip4market.ru> <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> <339541436713152@web17j.yandex.ru> <474201436721143@web20h.yandex.ru> Message-ID: <55A2A3C2.2070607@nethinks.com> Guten Tag, > What do you mean cheap talk? > One company can not setup more than one account. Is it enough for you? ... > I don't see any reasons of this proposal creation. Here are people who can calculate all part of the transfers. But they are lazy and trust for WG. (was it you who complained earlier about personal attacks or insults? Do you have to stoop so low yourself?) Creating a proposal is the first step to a policy change - or, possibly, delaying this change. Putting some more "meat" on your above proposal isn't that much work - instead of whining about people not understanding you and purposefully wanting to deplete the IPv4 pool, why don't you take that time (judging from the amount of posts you made over the last couple week, it must have been quite an amount) and put together your suggestion in the form of a policy proposal, explaining the short-falls of 2015-1 and why your suggestion - possibly in addition to 2015-1? - fixes the problem better? Currently, your ramblings have just put off people, hurting your cause more than helping it ... From what I have read, several (many/most?) on the group do know that the current proposal isn't the final fix for the problem, so going at this CONSTRUCTIVELY will most likely get you support from the community ... -garry From gert at space.net Sun Jul 12 21:04:59 2015 From: gert at space.net (Gert Doering) Date: Sun, 12 Jul 2015 21:04:59 +0200 Subject: [address-policy-wg] Opposing policy 2015-01 In-Reply-To: References: <1574631436123127@web21h.yandex.ru> <29CE2372-FDF1-402A-9E10-00BB7FC82EBA@rfc1035.com> <672321436635816@web13j.yandex.ru> <1803781436640460@web11h.yandex.ru> <481871436644610@web25j.yandex.ru> <20150712141545.GB67883@Space.Net> Message-ID: <20150712190459.GD67883@Space.Net> Hi, On Sun, Jul 12, 2015 at 07:06:41PM +0200, Richard Hartmann wrote: > Procedural question: 2015-01 is still on track and this thread is not > influencing it in any way, correct? So far, I have not seen any new arguments against 2015-01, and neither any procedural issues raised. In other words: we're in Last Call = concluding phase, and I do not see anything that would hold up declaration of (rough) consensus when it ends (but for neutrality reasons, I'll leave that particular judgement to Sander again). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe at opteamax.de Sun Jul 12 23:33:16 2015 From: ripe at opteamax.de (Opteamax GmbH) Date: Sun, 12 Jul 2015 23:33:16 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150712085438.1dd1e832@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> <20150712085438.1dd1e832@envy.fud.no> Message-ID: <55A2DD1C.30402@opteamax.de> Hi Tore, On 12.07.2015 08:54, Tore Anderson wrote: > Hi Jens, > > * Opteamax GmbH > >> as far as I am informed each V6- allocation made by RIPE had always a >> "reserved" space after the actual allocation which allows "extending" >> upto /27 ... so returning seems not to be necassary ... at least not >> as long as /27 is sufficient. > > Actually, the reservation is for a /29. That's precisely the reason why > the 6RD proposal allowed for extension up to that exact size: for a customer, I had a request for a /28 opened recently and were offered to start with a /29 and maybe resize it to /28 depending on outcome of 2015-03. I asked back if "resize" means new allocation so renumbering and received the following reply for RIPE-Staff: > We actually reserve 3 bits for each allocation so in future if > needed your user would have access up to a /26. I just downloaded ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz and grep'ed for /29 $ grep "/29" ripe.db.inet6num | sort I did not validate each and every line, but paged thru the output and it actually seems that the allocations made are all with a following reserved space that they can be grown upto /26: inet6num: 2a06:d00::/29 inet6num: 2a06:d40::/29 inet6num: 2a06:d80::/29 inet6num: 2a06:dc0::/29 inet6num: 2a06:e00::/29 inet6num: 2a06:e40::/29 inet6num: 2a06:e80::/29 inet6num: 2a06:ec0::/29 inet6num: 2a06:f00::/29 inet6num: 2a06:f40::/29 inet6num: 2a06:f80::/29 inet6num: 2a06:fc0::/29 Sorry in my last mail I remembered wrongly that it was /27 instead of /26 BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From tore at fud.no Mon Jul 13 06:32:07 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 13 Jul 2015 06:32:07 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <55A2DD1C.30402@opteamax.de> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> <20150712085438.1dd1e832@envy.fud.no> <55A2DD1C.30402@opteamax.de> Message-ID: <20150713063207.3856397f@envy.fud.no> Hi Jens, * Opteamax GmbH > for a customer, I had a request for a /28 opened recently and were > offered to start with a /29 and maybe resize it to /28 depending on > outcome of 2015-03. I asked back if "resize" means new allocation so > renumbering and received the following reply for RIPE-Staff: > > > We actually reserve 3 bits for each allocation so in future if > > needed your user would have access up to a /26. You should ask that IPRA should re-read 2015-03. If your customer is allocated a /29, the new allocation criteria currently proposed in 2015-03 can simply *not* be used to "resize" it to a /28. This is, as I've mentioned earlier, due to the fact that 2015-03 only changes the *initial* allocation criteria. If already allocated a /29, your customer would need to request a *subsequent* allocation in order to obtain a /28, but as the subsequent allocation criteria is not changed by 2015-03, it won't be of any help as far as your customer's concerned. The Impact Analysis says: ?It is important to note that the suggested policy change could also have impact on the evaluation of subsequent IPv6 allocation requests. LIRs that request an initial allocation under the proposed new assessment criteria might find it difficult to reach a sufficient HD-ratio in the future, as a significant amount of address space will be reserved for network structuring and future growth. Meeting the specified HD-ratio is required to qualify for a subsequent IPv6 allocation.? If your customer would qualify for a /28 under the 2015-03 criteria, I'd advise patience - have your customer wait until 2015-03 is implemented, at which point you can submit an *initial* allocation request for a /28. > I just downloaded > ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz and grep'ed for /29 > > $ grep "/29" ripe.db.inet6num | sort > > I did not validate each and every line, but paged thru the output and it > actually seems that the allocations made are all with a following > reserved space that they can be grown upto /26: That is only the case if the allocation was a /29 to begin with. If it started out as a /32, and was extended to a /29 (most likely under the 6RD policy), then it can be expanded no further. Matthew's allocation, 2001:40c8::/29, is an example of this - the covering /28 contains other unrelated allocations: $ whois -h whois.ripe.net -- -m 2001:40c8::/28 | egrep '^(inet6num|netname):' inet6num: 2001:40c0::/32 netname: CH-SAFEHOST-20040726 inet6num: 2001:40c8::/29 netname: UK-MOD-20070802 Tore From Mathew.Newton643 at official.mod.uk Mon Jul 13 12:31:04 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Mon, 13 Jul 2015 10:31:04 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150713063207.3856397f@envy.fud.no> References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> <20150712085438.1dd1e832@envy.fud.no> <55A2DD1C.30402@opteamax.de> <20150713063207.3856397f@envy.fud.no> Message-ID: Tore, > You should ask that IPRA should re-read 2015-03. If your customer is > allocated a /29, the new allocation criteria currently proposed in > 2015-03 can simply *not* be used to "resize" it to a /28. This is, as > I've mentioned earlier, due to the fact that 2015-03 only changes the > *initial* allocation criteria. If already allocated a /29, your > customer would need to request a *subsequent* allocation in order to > obtain a /28, but as the subsequent allocation criteria is not changed > by 2015-03, it won't be of any help as far as your customer's concerned. The 2015-03 proposal might still help/apply if you view the situation as being that the customer has not *outgrown* their /29 allocation (and hence needs consideration under the subsequent allocation policy) but rather that they have effectively *ordered the wrong size* in which case they could return the /29 and get a /28 in return under the new initial allocation criteria. If the /28 is able to encompass the first then this obviously carries the benefit of not requiring any renumbering. This is just speculation though and so, for clarity of understanding, it would be good to hear how RIPE NCC would see things operating in such a scenario... Mathew From ingrid at ripe.net Mon Jul 13 15:14:27 2015 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 13 Jul 2015 15:14:27 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150710144409.6e127352@envy.fud.no> <20150710190243.356f6bc8@envy.fud.no> <386E1D12-15BA-418A-8E95-F0617AFC6FB9@opteamax.de> <20150712085438.1dd1e832@envy.fud.no> <55A2DD1C.30402@opteamax.de> <20150713063207.3856397f@envy.fud.no> Message-ID: <55A3B9B3.7070505@ripe.net> Hi Mathew, Thanks for your question. As previously mentioned on the mailing list, LIRs can return unused previously-allocated IPv6 blocks if they believe their initial deployment plans require more than a /29. If a bigger allocation size is justified, the RIPE NCC will allocate a new range with the according reservation to allow for future aggregation. If an LIR has already started to deploy IPv6 from their current allocation and would like additional IPv6 space, the subsequent allocation policy applies: https://www.ripe.net/publications/docs/ripe-641#subsequent_allocation Where possible, the allocation will be made from an adjacent address block. I hope this answers your question. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 13/07/15 12:31, Mathew Newton wrote: > Tore, > >> You should ask that IPRA should re-read 2015-03. If your customer is >> allocated a /29, the new allocation criteria currently proposed in >> 2015-03 can simply *not* be used to "resize" it to a /28. This is, as >> I've mentioned earlier, due to the fact that 2015-03 only changes the >> *initial* allocation criteria. If already allocated a /29, your >> customer would need to request a *subsequent* allocation in order to >> obtain a /28, but as the subsequent allocation criteria is not changed >> by 2015-03, it won't be of any help as far as your customer's concerned. > The 2015-03 proposal might still help/apply if you view the situation as being that the customer has not *outgrown* their /29 allocation (and hence needs consideration under the subsequent allocation policy) but rather that they have effectively *ordered the wrong size* in which case they could return the /29 and get a /28 in return under the new initial allocation criteria. If the /28 is able to encompass the first then this obviously carries the benefit of not requiring any renumbering. > > This is just speculation though and so, for clarity of understanding, it would be good to hear how RIPE NCC would see things operating in such a scenario... > > Mathew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at list.ak.cx Mon Jul 13 19:42:40 2015 From: ak at list.ak.cx (Andre Keller) Date: Mon, 13 Jul 2015 19:42:40 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <55A3F890.7080006@list.ak.cx> Hi, On 09.07.2015 14:19, Marco Schmidt wrote: > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 7 August 2015. tl;dr: I support the proposal in the current state. I do not really think this will help the routing table growth as outlined in section B of the impact analysis though. The organisations that are likely to request address space under the proposed rules will probably announce the received address space with some sort of de-aggregation. But I do think this proposal can remove constraints some organisation currently have when deploying (or trying to deploy) IPv6. g Andr? From sander at steffann.nl Tue Jul 14 01:18:40 2015 From: sander at steffann.nl (Sander Steffann) Date: Tue, 14 Jul 2015 01:18:40 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <55A3F890.7080006@list.ak.cx> References: <55A3F890.7080006@list.ak.cx> Message-ID: Hi Andr?, > On 09.07.2015 14:19, Marco Schmidt wrote: >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 7 August 2015. > > tl;dr: I support the proposal in the current state. > > I do not really think this will help the routing table growth as > outlined in section B of the impact analysis though. The organisations > that are likely to request address space under the proposed rules will > probably announce the received address space with some sort of > de-aggregation. > > But I do think this proposal can remove constraints some organisation > currently have when deploying (or trying to deploy) IPv6. I have already been thinking about the de-aggregation, and especially for national networks I think there are ways to keep that under control. But that's not really address policy related. I'll take it to our Routing WG. Cheers, Sander From LIR at bva.bund.de Fri Jul 17 11:08:48 2015 From: LIR at bva.bund.de (LIR (BIT I 5)) Date: Fri, 17 Jul 2015 09:08:48 +0000 Subject: [address-policy-wg] [policy-announce] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <559FB736.8030003@ripe.net> References: <559FB736.8030003@ripe.net> Message-ID: Hi, I support this proposal. The change allows large organizations with complex network infrastructures or special purposes the deployment of ipv6 based on a complete, useful structured and sustainable ipv6 address plan. Regards, Carsten -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Freitag, 10. Juli 2015 14:15 An: Mathew Newton; address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] [policy-announce] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Hi Matthew, Thanks for your question - it's good to be able to clarify. If the proposal is accepted, we would base our evaluation of IPv6 requests on the number of actual end sites. An LIR could then document its need for addresses according to a range of criteria such as longevity, security requirements for an end site, or the need for aggregation in the hierarchy level of that end site and higher levels in the network topology. This is what is meant by encapsulation of the assignment. An end site cannot be repeated in another part of the addressing plan to qualify again under the same assessment criteria -- this would be a multiplication of the same assignment. So, for example, it would be possible to request extra address space for security and above hierarchy for the same end site, but it would not be possible to mention the same end site again in another part of the addressing plan to request a further reservation for security and hierarchy. I hope this helps. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC On 09/07/15 18:18, Mathew Newton wrote: > Hi Marco, > >> -----Original Message----- >> From: policy-announce [mailto:policy-announce-bounces at ripe.net] On >> Behalf Of Marco Schmidt >> Sent: 09 July 2015 13:20 >> The draft document for version 2.0 of the policy proposal 2015-03, >> "Assessment Criteria for IPv6 Initial Allocation Size", has now been >> published, along with an impact analysis conducted by the RIPE NCC. > Thank you to you and colleagues for this. It can't have been the easiest analysis to undertake, not least given the multiple aspects to consider. It is clear however that a great deal of thought and consideration has gone into it. > > I need to take some time to fully consider all of the detail however my initial view of the interpretation and proposed implementation is very positive. > > Could I possibly seek some clarification on the following sentence from the second-to-last paragraph of Section A? > > 'Each assignment will be taken into account only once towards the total count of needed IPv6 space for an organisation and will not be multiplied by the times it is encapsulated in higher addressing plan levels.' > > Whilst I don't have a specific concern, and it may well be an insignificant statement, I thought it worthwhile double-checking what this means? > > Regards, > > Mathew > > > From sander at steffann.nl Wed Jul 22 14:13:55 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 22 Jul 2015 14:13:55 +0200 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations Message-ID: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> Hello working group, We have reached the end of the last-call period for 2015-01 (Alignment of Transfer Requirements for IPv4 Allocations). After analysing the messages on the mailing list that were posted about 2015-01 after the last-call was announced I have come to the conclusion that the consensus declared at the end of the review phase still stands. I therefore declare final consensus on this policy proposal and ask the RIPE NCC to turn it into active policy and implement it. My decision is based on the following: Shahin Gharghi, Petr Umelov and Yuri at Ip4market argued that this proposal doesn't solve all problems. This has already been discussed and acknowledged during the review phase. No policy proposal will ever solve everything all at once. People wanting additional changes are encouraged to submit new policy proposals to address any remaining issues. Petr Umelov was under the impression that RIPE NCC receives a fixed size IPv4 block from IANA every 6 months, which is not correct as pointed out by Leo Vegoda. Petr Umelov and Vladimir Andreev also discussed the statistics on transfers and whether the trend justifies changing policy. Arguments that RIPE NCC has enough address space and a policy change would therefore not be necessary have already been discussed in the review phase and are considered addressed. Vladimir Andreev suggested writing a summary of the discussions so I hope he reads this email. Arash Naderpour argued that with 2015-01 existing LIRs cannot request their last /22 and then immediately transfer it. This has been discussed before: it is one of the actual goals of this policy: to stop LIRs from requesting a /22 just to transfer it. Sincerely, Sander Steffann APWG co-chair From nikolas.pediaditis at ripe.net Wed Jul 22 15:54:33 2015 From: nikolas.pediaditis at ripe.net (Nikolas Pediaditis) Date: Wed, 22 Jul 2015 15:54:33 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-12, "Allow IPv6 Transfers" Message-ID: <38A2F1DD-55A9-4F52-A27F-58CC134328C8@ripe.net> Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-12, "Allow IPv6 Transfers". In accordance with the new policy, any holder of IPv6 address space is allowed to transfer complete or partial blocks of IPv6 address space that were previously allocated or assigned to them by the RIPE NCC. Please note that blocks being transferred must not be smaller than the minimum allocation/assignment size at the time of the transfer: - For IPv6 allocations this is currently a /32 - For IPv6 PI assignments this is currently a /48 The archived policy proposal can be found at: https://www.ripe.net/ripe/policies/proposals/2014-12 The updated RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available at: https://www.ripe.net/publications/docs/ripe-641 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services From nikolas.pediaditis at ripe.net Wed Jul 22 16:01:57 2015 From: nikolas.pediaditis at ripe.net (Nikolas Pediaditis) Date: Wed, 22 Jul 2015 16:01:57 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-13, "Allow AS Number Transfers" Message-ID: Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-13, "Allow AS Number Transfers?. In accordance with the new policy, any holder of Autonomous System (AS) Numbers is allowed to re-assign AS Numbers that were previously assigned to them by the RIPE NCC The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2014-13 The updated RIPE Document, "Autonomous System (AS) Number Assignment Policies", is available at: https://www.ripe.net/publications/docs/ripe-638 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services From petr at fast-telecom.net Wed Jul 22 17:37:40 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Wed, 22 Jul 2015 18:37:40 +0300 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations In-Reply-To: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> References: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> Message-ID: <864371437579460@web13h.yandex.ru> 22.07.2015, 15:14, "Sander Steffann" : > ?Hello working group, > > ?Shahin Gharghi, Petr Umelov and Yuri at Ip4market argued that this proposal doesn't solve all problems. This has already been discussed and acknowledged during the review phase. No policy proposal will ever solve everything all at once. People wanting additional changes are encouraged to submit new policy proposals to address any remaining issues. If it wouldn't solve the problems - this would be okay and we could start new proposal, described this unresolved problems. But this proposal will increase multiple LIR accounts creation and the number of IPv4 will be decrease. Why don't you understand it? > ?Petr Umelov was under the impression that RIPE NCC receives a fixed size IPv4 block from IANA every 6 months, which is not correct as pointed out by Leo Vegoda. But the RIPE NCC receives a fixed size. But you don't consider it. > > ?Sincerely, > ?Sander Steffann > ?APWG co-chair --? Kind regards, Petr Umelov From leo.vegoda at icann.org Wed Jul 22 18:04:05 2015 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 22 Jul 2015 16:04:05 +0000 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations In-Reply-To: <864371437579460@web13h.yandex.ru> References: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> <864371437579460@web13h.yandex.ru> Message-ID: <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi Petr, Petr Umelov wrote: [...] > > ?Petr Umelov was under the impression that RIPE NCC receives > > a fixed size IPv4 block from IANA every 6 months, which is not > > correct as pointed out by Leo Vegoda. > > But the RIPE NCC receives a fixed size. But you don't consider it. I do not understand what you mean. Can you please explain? In May 2014 the RIRs each received the equivalent of a /11. That dropped to a /12 in September 2014 and a /13 or equivalent in March 2015. Regards, Leo Vegoda From petr at fast-telecom.net Wed Jul 22 18:13:54 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Wed, 22 Jul 2015 19:13:54 +0300 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations In-Reply-To: <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> <864371437579460@web13h.yandex.ru> <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <1562291437581634@web22g.yandex.ru> I mean the next Frome: "Ingrid Wijte" Date: 3 March 2015 ?. 12:52 Subject: [ncc-announce] [news] RIPE NCC Receives a /13 from IANA's Recovered IPv4 Pool To: Dear colleagues, Yesterday, on 2 March 2015, the RIPE NCC and other Regional Internet Registries (RIRs) were each allocated a /13 of IPv4 address space from the Internet Assigned Numbers Authority (IANA). The RIPE NCC received the IPv4 address range 45.8.0.0/13 and we are currently adding this to our available pool. Following the exhaustion of IANA's free pool of IPv4 addresses in 2011, when the RIRs received their final /8s, a global policy caused IANA to create a recovered pool of leftover and returned IPv4 address blocks. This policy was ratified by all five RIR communities in 2012 and stated that IANA would begin making equal, periodic allocations from the recovered pool when the first RIR reached a /9 of remaining addresses. This point was reached by LACNIC, the RIR for Latin America and the Caribbean on 20 May 2014, triggering the global policy and the first post-exhaustion allocation from IANA. You can read the global policy here: http://www.icann.org/en/resources/policy/global-addressing/allocation-ipv4-post-exhaustion With the current policy in place, the RIPE NCC will receive one-fifth of any recovered addresses in the pool every six months (every March and September). The RIPE NCC will continue to distribute these according to the current last /8 policy, under which Local Internet Registries (LIRs) may receive a one-time /22 allocation (1,024 addresses). It is important that network operators continue to deploy IPv6 on their networks to ensure the future growth of the Internet. More information on IPv6 deployment can be found here: www.ipv6actnow.com With the current policy in place, the RIPE NCC will receive one-fifth of any recovered addresses in the pool every six months (every March and September). 22.07.2015, 19:04, "Leo Vegoda" : > Hi Petr, > > Petr Umelov wrote: > > [...] > >> ?> ?Petr Umelov was under the impression that RIPE NCC receives >> ?> a fixed size IPv4 block from IANA every 6 months, which is not >> ?> correct as pointed out by Leo Vegoda. >> >> ?But the RIPE NCC receives a fixed size. But you don't consider it. > > I do not understand what you mean. Can you please explain? In May 2014 the RIRs each received the equivalent of a /11. That dropped to a /12 in September 2014 and a /13 or equivalent in March 2015. > > Regards, > > Leo Vegoda --? Kind regards, Petr Umelov From petr at fast-telecom.net Wed Jul 22 18:16:49 2015 From: petr at fast-telecom.net (Petr Umelov) Date: Wed, 22 Jul 2015 19:16:49 +0300 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations In-Reply-To: <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> <864371437579460@web13h.yandex.ru> <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <1572301437581809@web22g.yandex.ru> I mean the next From: "Ingrid Wijte" Date: 3 March 2015 ?. 12:52 Subject: [ncc-announce] [news] RIPE NCC Receives a /13 from IANA's Recovered IPv4 Pool To: Dear colleagues, Yesterday, on 2 March 2015, the RIPE NCC and other Regional Internet Registries (RIRs) were each allocated a /13 of IPv4 address space from the Internet Assigned Numbers Authority (IANA). The RIPE NCC received the IPv4 address range 45.8.0.0/13 and we are currently adding this to our available pool. Following the exhaustion of IANA's free pool of IPv4 addresses in 2011, when the RIRs received their final /8s, a global policy caused IANA to create a recovered pool of leftover and returned IPv4 address blocks. This policy was ratified by all five RIR communities in 2012 and stated that IANA would begin making equal, periodic allocations from the recovered pool when the first RIR reached a /9 of remaining addresses. This point was reached by LACNIC, the RIR for Latin America and the Caribbean on 20 May 2014, triggering the global policy and the first post-exhaustion allocation from IANA. You can read the global policy here: http://www.icann.org/en/resources/policy/global-addressing/allocation-ipv4-post-exhaustion With the current policy in place, the RIPE NCC will receive one-fifth of any recovered addresses in the pool every six months (every March and September). The RIPE NCC will continue to distribute these according to the current last /8 policy, under which Local Internet Registries (LIRs) may receive a one-time /22 allocation (1,024 addresses). It is important that network operators continue to deploy IPv6 on their networks to ensure the future growth of the Internet. More information on IPv6 deployment can be found here: www.ipv6actnow.com With the current policy in place, the RIPE NCC will receive one-fifth of any recovered addresses in the pool every six months (every March and September). 22.07.2015, 19:04, "Leo Vegoda" : > ?Hi Petr, > > ?Petr Umelov wrote: > > ?[...] > >> ??> ?Petr Umelov was under the impression that RIPE NCC receives >> ??> a fixed size IPv4 block from IANA every 6 months, which is not >> ??> correct as pointed out by Leo Vegoda. >> >> ??But the RIPE NCC receives a fixed size. But you don't consider it. > > ?I do not understand what you mean. Can you please explain? In May 2014 the RIRs each received the equivalent of a /11. That dropped to a /12 in September 2014 and a /13 or equivalent in March 2015. > > ?Regards, > > ?Leo Vegoda --? Kind regards, Petr Umelov From sander at steffann.nl Wed Jul 22 18:24:07 2015 From: sander at steffann.nl (Sander Steffann) Date: Wed, 22 Jul 2015 18:24:07 +0200 Subject: [address-policy-wg] Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations In-Reply-To: <1562291437581634@web22g.yandex.ru> References: <875D6327-497A-4FA0-9871-E9221C3D0AB8@steffann.nl> <864371437579460@web13h.yandex.ru> <616cb54dd94746aa9e5796698e7483d1@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <1562291437581634@web22g.yandex.ru> Message-ID: Hi Petr, > I mean the next > > Frome: "Ingrid Wijte" > Date: 3 March 2015 ?. 12:52 > > Subject: [ncc-announce] [news] RIPE NCC Receives a /13 from IANA's Recovered IPv4 Pool > To: > > [...] > > With the current policy in place, the RIPE NCC will receive one-fifth of > any recovered addresses in the pool every six months (every March and > September). This is not a fixed size. As Leo has already shown you the size RIPE NCC gets has been smaller each time. But to avoid any lengthy discussions on 2015-01: it has been *concluded*. As working group chair I have made my decision and I decided that there is consensus on 2015-01. If you do not agree with this decision then please use the appeals procedure [1]. There is no point in discussing this any further on this mailing list as I have thoroughly reviewed everything and I stand by my decisions. Cheers, Sander [1] https://www.ripe.net/publications/docs/ripe-642 section 4 From LIR at bva.bund.de Thu Jul 23 09:27:18 2015 From: LIR at bva.bund.de (LIR (BIT I 5)) Date: Thu, 23 Jul 2015 07:27:18 +0000 Subject: [address-policy-wg] =?windows-1252?q?_2015-03_New_Draft_Document_?= =?windows-1252?q?and_Impact_Analysis_Published_=28Assessment_Criteria_for?= =?windows-1252?q?_IPv6_Initial_Allocation_Size=29_-_=93subsequent_allocat?= =?windows-1252?q?ions=94?= Message-ID: <8508FF468849BE46A0FB0661E72BAC360FD953@S01KR975.intern.dir> Hi community, hi Tore, the LIR-team of de.government supports this current policy proposal ?2015-03 New Draft Document?. +1 In addition we also made up our mind about the resulting inconsistency to the criteria for subsequent allocations. Therefore we plan to propose a ?follow-up? proposal which tries to align the subsequent allocation criteria in case of a successful 2015-03 PDP. Kind regards, Annette Suedmeyer LIR de.government ------------------------------------- Bundesverwaltungsamt Bundesstelle f?r Informationstechnik (BIT) BIT I 5 Besucheradresse: Barbarastr.1 in 50735 K?ln (Riehl) Servicezeiten: Montag bis Freitag 08:00 Uhr bis 16:30 Uhr Postadresse: Bundesverwaltungsamt, Barbarastra?e 1, 50728 K?ln Telefon: +49 22899 358 3551 E-Mail: annette.suedmeyer at bva.bund.de Internet: www.bundesverwaltungsamt.de www.bit.bund.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Jul 23 11:43:34 2015 From: sander at steffann.nl (Sander Steffann) Date: Thu, 23 Jul 2015 11:43:34 +0200 Subject: [address-policy-wg] =?windows-1252?q?2015-03_New_Draft_Document_a?= =?windows-1252?q?nd_Impact_Analysis_Published_=28Assessment_Criteria_for_?= =?windows-1252?q?IPv6_Initial_Allocation_Size=29_-_=93subsequent_allocati?= =?windows-1252?q?ons=94?= In-Reply-To: <8508FF468849BE46A0FB0661E72BAC360FD953@S01KR975.intern.dir> References: <8508FF468849BE46A0FB0661E72BAC360FD953@S01KR975.intern.dir> Message-ID: <69F471E4-9A45-48BA-9D76-CB150A5B2D21@steffann.nl> Hello Annette, > the LIR-team of de.government supports this current policy proposal ?2015-03 New Draft Document?. +1 > > In addition we also made up our mind about the resulting inconsistency to the criteria for subsequent allocations. Therefore we plan to propose a ?follow-up? proposal which tries to align the subsequent allocation criteria in case of a successful 2015-03 PDP. Ok, we'll see how 2015-03 goes and contact you once that has been concluded (either withdrawn or accepted). If you have any questions feel free to contact the chairs and RIPE NCC PDO at apwg-chairs at ripe.net, or to follow up on this list of course. Cheers, Sander From mschmidt at ripe.net Thu Jul 23 13:50:53 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Jul 2015 13:50:53 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-643, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. This policy change aligns the transfer requirements for all IPv4 allocations. LIRs that receive an IPv4 allocation from the RIPE NCC or via a transfer cannot subsequently transfer this allocation to another party within 24 months. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-01 The new RIPE Document is called ripe-649 and is available at: https://www.ripe.net/publications/docs/ripe-649 This proposal is implemented with immediate effect. Please note that: - All IPv4 allocation transfer requests received by the RIPE NCC after this announcement will be evaluated under the new policy. - The evaluation of transfer requests received before this announcement will be completed under the previous policy. This policy change particularly concerns IPv4 allocations made by the RIPE NCC. If the RIPE NCC made the allocation less than 24 months ago, the allocation cannot be transferred until the defined holding period has passed. Regards, Marco Schmidt Policy Development Officer RIPE NCC From aleksbulgakov at gmail.com Thu Jul 23 17:31:27 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 23 Jul 2015 18:31:27 +0300 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: Hi. Be ready to IPv4 exhaustion and don't tell that you haven't been warned :) 23 ??? 2015 ?. 14:52 ???????????? "Marco Schmidt" ???????: > Dear colleagues, > > Consensus has been reached, and the proposal for a change to ripe-643, > "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service > Region", > has been accepted by the RIPE community. > > This policy change aligns the transfer requirements for all IPv4 > allocations. > LIRs that receive an IPv4 allocation from the RIPE NCC or via a transfer > cannot > subsequently transfer this allocation to another party within 24 months. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-01 > > The new RIPE Document is called ripe-649 and is available at: > > https://www.ripe.net/publications/docs/ripe-649 > > > This proposal is implemented with immediate effect. Please note that: > > - All IPv4 allocation transfer requests received by the RIPE NCC after > this announcement will be evaluated under the new policy. > - The evaluation of transfer requests received before this announcement > will be completed under the previous policy. > > This policy change particularly concerns IPv4 allocations made by the RIPE > NCC. > If the RIPE NCC made the allocation less than 24 months ago, the > allocation cannot > be transferred until the defined holding period has passed. > > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvia.hagen at sunny.ch Fri Jul 24 13:31:54 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Fri, 24 Jul 2015 11:31:54 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Message-ID: Hi to all +1 I fully support this proposal. I believe it is an important step to allow for useful deployment of IPv6 taking advantage of the advanced and extended IPv6 address architecture. Responding to the request for feedback on the "RIPE understanding" section here are some thoughts and comments: - The overall tone of the "understanding" section still sounds more like "our main goal is to preserve addresses" instead of "let's make generous use oft he extended address architecture and available space" to me. It is not easy to step out of IPv4 thinking. While we all know in our minds that we need to do this, implementing it is much more difficult. (I am for instance referring to this sentence, which appears more than once: " The RIPE NCC will ask for additional documentation to justify why a less address consuming hierarchy or topology can not be implemented."). There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans. - There is one point where I have a problem to understand, maybe I am misinterpreting the statement. It says " The RIPE NCC will consider longevity reasonable for a similar timeframe for which past growth was documented." - So my question is: how does this accomodate startups? We are moving into the age of the Internet of Things. We expect new technologies and services to spring up, not foreseeable. This includes new business models and opportunities for new companies that have no history. - The policy for subsequent allocations will have to be updated accordingly if this policy is accepted. - Quote: "If this network topology is justified, the RIPE NCC will consider up to one extra bit per hierarchical level or geographical segment as reasonable, on top of the documented need for that part of the network." Comment: how about "generally up to one bit" - leave room for exceptions. - The rules seem quite complicated and a bit hard to really understand and correctly apply to me. I wonder how easy it will be to assess requests based on this. As mentioned already, I believe this proposal is a good step. When it comes to how to apply it, I feel there is a lot of "strictness" in the wording. It is always nice to have clear and strict rules, everyone can easily apply them. But reality is different. There is no good rule without exceptions and I hope that this policy will be applied with common sense and adjusted to reality. And my personal viewpoint is, that we should not restrict IPv6 address plans from the beginning. Our main target should be to finally DEPLOY it as broadly as possible and have ease of operation as a main goal. That is what the address architecture provides. By today we have given out the equivalent of 171'000 /32 of the currently defined global unicast space (2000::/3) (according to Bgpexpert) and this equals 0.032%. Hey that is 171'000 times more than the whole current Internet and we are at 0.032%! I think we should apply a generous allocation model that makes it easy to deploy, operate, secure..... ...and if we get to the point where we feel we have been too generous, we can still adjust policies and become more careful. Once we have used 2000::/3 we still have 7 more chances to do better. We could even define a re-assessment once we are 30% or 50% into the 2000::/3. My two cents, greetings from the summer heat Silvia Hagen Chair Swiss IPv6 Council -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 9. Juli 2015 14:20 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC Sunny Connection AG CH-8124 Maur +41 (0)44 887 62 10 www.sunny.ch http://twitter.com/sunny_shagen ****************************************** IPv6 Business Conference, June 18, 2015, Zurich International Top Speakers, Unique Program Great Networking - watch out for the 2016 Conference ****************************************** Switzerland is in the Top 5 in IPv6 User Adoption We reached 21% in June 2015! *********************************** Our website is dual-stack - how about yours? *********************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Jul 24 13:50:40 2015 From: gert at space.net (Gert Doering) Date: Fri, 24 Jul 2015 13:50:40 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <20150724115040.GE84167@Space.Net> Hi, On Fri, Jul 24, 2015 at 11:31:54AM +0000, Silvia Hagen wrote: > There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans. You can't do that on a RIR level - if the IPRAs were to hand out a /16 for everyone that comes with a nice diagram, we'd actually run out of IPv6 soon. Of course a /16 is excaggerating a bit - but I have seen my share of network plans made totally without understanding for bits, hierarchy or actual *networking*, resulting in "oh, for these 500 sites, we definitely need a /24!" (and "oh, for all the electronic passports for 100 million citizens, we must have a /19!") - and thus it is good practice to have someone more experienced in addressing review the plan and see whether it makes sense. (Just to point out the obvious - from the early days of /35s I have been fighting for more liberal IPv6 allocation policies, but it still needs to be done with a solid technical understanding, and not with "I like large numbers, so get me a /15 please!" - this is the balance we need to find, or otherwise we'll find us faster than expected in the "oops, fp 001 is gone!" land) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From silvia.hagen at sunny.ch Fri Jul 24 14:02:31 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Fri, 24 Jul 2015 12:02:31 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150724115040.GE84167@Space.Net> References: <20150724115040.GE84167@Space.Net> Message-ID: Hi Gert Sure, I fully agree with what you are saying, that is actually what I meant with "use common sense". So we add to that "and with the necessary technical understanding". The reason that I made the statement from this perspective is that in my consultings I have seen a lot more oft he restricted thinking (like when a global organization says: "we got a /48 and I guess we will find a way to live with that, it is more than we ever had".... :-) So let's go for balance :-) Silvia -----Urspr?ngliche Nachricht----- Von: Gert Doering [mailto:gert at space.net] Gesendet: Freitag, 24. Juli 2015 13:51 An: Silvia Hagen Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Hi, On Fri, Jul 24, 2015 at 11:31:54AM +0000, Silvia Hagen wrote: > There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans. You can't do that on a RIR level - if the IPRAs were to hand out a /16 for everyone that comes with a nice diagram, we'd actually run out of IPv6 soon. Of course a /16 is excaggerating a bit - but I have seen my share of network plans made totally without understanding for bits, hierarchy or actual *networking*, resulting in "oh, for these 500 sites, we definitely need a /24!" (and "oh, for all the electronic passports for 100 million citizens, we must have a /19!") - and thus it is good practice to have someone more experienced in addressing review the plan and see whether it makes sense. (Just to point out the obvious - from the early days of /35s I have been fighting for more liberal IPv6 allocation policies, but it still needs to be done with a solid technical understanding, and not with "I like large numbers, so get me a /15 please!" - this is the balance we need to find, or otherwise we'll find us faster than expected in the "oops, fp 001 is gone!" land) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gert at space.net Fri Jul 24 14:08:51 2015 From: gert at space.net (Gert Doering) Date: Fri, 24 Jul 2015 14:08:51 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: <20150724115040.GE84167@Space.Net> Message-ID: <20150724120851.GG84167@Space.Net> Hi, On Fri, Jul 24, 2015 at 12:02:31PM +0000, Silvia Hagen wrote: > So let's go for balance :-) All for it! Plus "good documentation and good understanding of networking" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From apwg at c4inet.net Fri Jul 24 14:17:43 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Fri, 24 Jul 2015 13:17:43 +0100 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: Message-ID: <20150724121743.GC93095@cilantro.c4inet.net> On Fri, Jul 24, 2015 at 12:02:31PM +0000, Silvia Hagen wrote: >So let's go for balance :-) I agree. I think a sensible balance may be that allocations >/29 are reviewed (as they are now, AIUI) by the IPRA managers and/or the Board. There is a danger, in my opinion, that the IPv6 allocation/assignment process is infested with "IPv4 thinking" which will result in SPs employing "workarounds" of the sort that made IPv4 such a pain to deal with. That said, I've done a bit of v6 IPAM recently and the numbers one deals with are staggering. ;p rgds, Sascha Luck From Mathew.Newton643 at official.mod.uk Fri Jul 24 15:14:24 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Fri, 24 Jul 2015 13:14:24 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150724115040.GE84167@Space.Net> References: <20150724115040.GE84167@Space.Net> Message-ID: Hi Gert, > I have seen my share of network plans made totally without understanding for > bits, hierarchy or actual *networking*, resulting in "oh, for these 500 sites, we > definitely need a /24!" (and "oh, for all the electronic passports for 100 million > citizens, we must have a /19!") - and thus it is good practice to have > someone more experienced in addressing review the plan and see whether > it makes sense. I think that is the general point that Silvia is making... It is very difficult, if not impossible, to come up with a one-size-fits all approach to assessing requests for address space, particularly when trying to cater for organisations that don't quite fit the usual mould. Are approaches such as 'up to one extra bit per hierarchical level or geographical segment' compatible with this premise and are they even necessary? I know from personal experience of assessing hundreds of requests for IPv4 address ranges over the years within my own organisation that there is no substitute for experience when it comes to performing the task effectively. Whilst rules of thumb are useful I think that attempts to 'proceduralise' the task with more specifics can end up being unhelpful and, in any event, are not necessary prerequisites for consistency. In my view what is more important is general oversight and capturing of experience garnered over multiple requests and it is noted from the IA that >/29 requests will continue to follow the escalated evaluation process which ought to help provide this. To be clear about where I stand; I am still satisfied that the revised policy and its proposed implementation will meet the needs of the UK MOD however I would nevertheless support a more 'liberal' approach to the consideration of the varying requirements of other organisations who will undoubtedly have different - yet equally valid - priorities and needs. Regards, Mathew From Mathew.Newton643 at official.mod.uk Fri Jul 24 16:12:21 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Fri, 24 Jul 2015 14:12:21 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150724115040.GE84167@Space.Net> References: <20150724115040.GE84167@Space.Net> Message-ID: Gert, Apologies I missed this bit in my first response: > (Just to point out the obvious - from the early days of /35s I have been > fighting for more liberal IPv6 allocation policies, but it still needs to > be done with a solid technical understanding, and not with "I like large > numbers, so get me a /15 please!" - this is the balance we need to find, > or otherwise we'll find us faster than expected in the "oops, fp 001 is > gone!" land) I fully agree with this but would ask that you are careful not to inadvertently imply that all large requests are necessarily a result of technical ignorance and/or disregard for what is still a finite shared resource. Some will be I am sure but there will be many that are the result of considerable effort being put into identifying requirements and establishing a sensible and robust addressing strategy to satisfy them. I think we should be careful that we don't focus too much on constraining the former but end up having an even bigger negative impact on the latter. As you say; it really is all about balance. Mathew From ripe at europeiptv.net Sat Jul 25 18:14:51 2015 From: ripe at europeiptv.net (ripe at europeiptv.net) Date: Sat, 25 Jul 2015 17:14:51 +0100 Subject: [address-policy-wg] =?utf-8?q?2015-01_Proposal_Accepted_and_Imple?= =?utf-8?q?mented=09=28Alignment_of_Transfer_Requirements_for_IPv4_Allocat?= =?utf-8?q?ions=29?= Message-ID: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> Hello, I do not see that the political right have retroactive effect, is not very democratic change the rules of what was received with other policies, but if I see the correct application of this policy to allocations received after this announcement, how do you see? Best Regards David IPTV EUROPE LTD. From poty at iiat.ru Sat Jul 25 19:11:44 2015 From: poty at iiat.ru (poty at iiat.ru) Date: Sat, 25 Jul 2015 17:11:44 +0000 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) Message-ID: <38A326B32984534586F211FB04239BF855F4B9E1@Win2008R2.office.iiat> Hello, I do not see any wrong cases here. When my company obtained our address block in 1998 there was one set of policies, since then the policies have been evolved a lot. Nobody asks you to return your address space or changes its USAGE rules, it's only transfer delays, not more, not less. Regards, Vladislav Potapov ________________________________ ??: ripe at europeiptv.net ??????????: ?25.?07.?2015 19:29 ????: address-policy-wg at ripe.net ????: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) Hello, I do not see that the political right have retroactive effect, is not very democratic change the rules of what was received with other policies, but if I see the correct application of this policy to allocations received after this announcement, how do you see? Best Regards David IPTV EUROPE LTD. From gert at space.net Sat Jul 25 21:36:37 2015 From: gert at space.net (Gert Doering) Date: Sat, 25 Jul 2015 21:36:37 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented?(Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> References: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> Message-ID: <20150725193637.GJ84167@Space.Net> Hi, On Sat, Jul 25, 2015 at 05:14:51PM +0100, ripe at europeiptv.net wrote: > Hello, I do not see that the political right have retroactive effect, is > not very democratic change the rules of what was received with other > policies, but if I see the correct application of this policy to > allocations received after this announcement, how do you see? This policy applies to all *transfers* from the moment the policy comes into effect - as it guidelines transfers. It's like putting up a speed limit somewhere - it will impact what you can do with your car at this particular place, but unless you are driving that road, nothing changes for car owners. Same here: unless you intend to short-transfer a last-/8 allocation, nothing changes for you. (Funny that people didn't complain when we changed the IPv6 allocation policy to permit /35 holders to extend their existing allocation to a /32 "just by asking for it" - *that* was a retroactive change of policy...) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From tore at fud.no Sun Jul 26 08:41:31 2015 From: tore at fud.no (Tore Anderson) Date: Sun, 26 Jul 2015 08:41:31 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented?(Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <20150725193637.GJ84167@Space.Net> References: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> <20150725193637.GJ84167@Space.Net> Message-ID: <20150726084131.52489058@envy.fud.no> * Gert Doering > (Funny that people didn't complain when we changed the IPv6 allocation > policy to permit /35 holders to extend their existing allocation to a /32 > "just by asking for it" - *that* was a retroactive change of policy...) Indeed. Or when we allowed transfers in the first place. Or when we allowed LIRs to make end-user assignments without filling in forms. Or when we further extended the /32 to /29 to accomodate for 6RD. Or when we allowed people to register any number of end-user assignments as a single AGGREGATED-BY-LIR object. Or... Tore From nick at inex.ie Sun Jul 26 14:34:31 2015 From: nick at inex.ie (Nick Hilliard) Date: Sun, 26 Jul 2015 13:34:31 +0100 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> References: <337907bf0eac0f00ad4c1008c90cecc3@europeiptv.net> Message-ID: <55B4D3D7.6080009@inex.ie> On 25/07/2015 17:14, ripe at europeiptv.net wrote: > Hello, I do not see that the political right have retroactive effect, is > not very democratic change the rules of what was received with other > policies, but if I see the correct application of this policy to > allocations received after this announcement, how do you see? if you are going to make this argument, you will also need to accept that IPv4 transfers are not applicable to ipv4 allocations made before 2009 because the ipv4 transfer policy (2007-08) was only implemented in 2009. Nick From ripe at europeiptv.net Sun Jul 26 18:08:23 2015 From: ripe at europeiptv.net (ripe at europeiptv.net) Date: Sun, 26 Jul 2015 17:08:23 +0100 Subject: [address-policy-wg] =?utf-8?q?Fwd=3A_2015-01_Proposal_Accepted_an?= =?utf-8?q?d_Implemented=09=28Alignment_of_Transfer_Requirements_for_IPv4_?= =?utf-8?q?Allocations=29?= Message-ID: Hello, The allocations made before the date of this announcement, should be governed by the old politics. is not serious things apply retroactively. On exhaustion, RIPE Why is not like other RIRs? Because RIPE accepts LIRs outside the region? without having a registered company and physical address in the RIPE Region? Other ARIN RIR as it met. Regards. David From sander at steffann.nl Sun Jul 26 18:43:22 2015 From: sander at steffann.nl (Sander Steffann) Date: Sun, 26 Jul 2015 18:43:22 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: Hello David, > Hello, The allocations made before the date of this announcement, should be governed by the old politics. The *transfers* made before the date of the announcement are handled by the old transfer policies, transfers made after that are made according to the new policy. The date the allocation was made is not relevant to determining which transfer policy is applied. Please stop discussing 2015-01 and its implementation. We have reached consensus and the policy has been implemented. If you want to change anything please submit a new policy proposal. Cheers, Sander From saeed at ipm.ir Mon Jul 27 13:55:54 2015 From: saeed at ipm.ir (Saeed Khademi) Date: Mon, 27 Jul 2015 15:25:54 +0330 Subject: [address-policy-wg] =?utf-8?q?2014-03=2C_=E2=80=9CRemove_Multihom?= =?utf-8?q?ing_Requirement_for_AS_Number_Assignments=E2=80=9D?= In-Reply-To: <38A326B32984534586F211FB04239BF855F4B9E1@Win2008R2.office.iiat> References: <38A326B32984534586F211FB04239BF855F4B9E1@Win2008R2.office.iiat> Message-ID: <2716BDE0323747EE9357A65DF72FC67F@Saeed> I have a quick question: As far as I know, having an AS number is necessary for BGP routing. Now my question is that, if a customer doesn't have multiple links ( at least 2 ) what is the use of having an AS number? Kind Regards, Saeed. From nick at inex.ie Mon Jul 27 13:53:21 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 27 Jul 2015 12:53:21 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-03=2C_=E2=80=9CRemove_Multihom?= =?utf-8?q?ing_Requirement_for_AS_Number_Assignments=E2=80=9D?= In-Reply-To: <2716BDE0323747EE9357A65DF72FC67F@Saeed> References: <38A326B32984534586F211FB04239BF855F4B9E1@Win2008R2.office.iiat> <2716BDE0323747EE9357A65DF72FC67F@Saeed> Message-ID: <55B61BB1.2060701@inex.ie> On 27/07/2015 12:55, Saeed Khademi wrote: > As far as I know, having an AS number is necessary for BGP routing. > Now my question is that, if a customer doesn't have multiple links ( at > least 2 ) > what is the use of having an AS number? they may want to become multihomed in the future. Nick From nick at inex.ie Mon Jul 27 13:56:40 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 27 Jul 2015 12:56:40 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-03=2C_=E2=80=9CRemove_Multihom?= =?utf-8?q?ing_Requirement_for_AS_Number_Assignments=E2=80=9D?= In-Reply-To: <55B61BB1.2060701@inex.ie> References: <38A326B32984534586F211FB04239BF855F4B9E1@Win2008R2.office.iiat> <2716BDE0323747EE9357A65DF72FC67F@Saeed> <55B61BB1.2060701@inex.ie> Message-ID: <55B61C78.5040309@inex.ie> On 27/07/2015 12:53, Nick Hilliard wrote: > On 27/07/2015 12:55, Saeed Khademi wrote: >> As far as I know, having an AS number is necessary for BGP routing. >> Now my question is that, if a customer doesn't have multiple links ( at >> least 2 ) >> what is the use of having an AS number? > > they may want to become multihomed in the future. oops, hit too quickly. They may also be providing l3vpn services, or providing BGP-to-customers for connectivity requirements. There are plenty of reasons to use an ASN which don't have anything to do with IP transit. Nick From mschmidt at ripe.net Mon Jul 27 16:01:27 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 27 Jul 2015 16:01:27 +0200 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: References: Message-ID: <55B639B7.8090604@ripe.net> Hi Silvia, Thanks for your feedback on our understanding of the policy. Regarding your point about start-ups - it can be difficult to make a fair evaluation on what is often a vague estimate of potential growth, and so the tendency here is to be somewhat cautious. On the other hand, we feel that our approach under the existing policy has been working well, and we have never had any issues or complaints from start-ups in the past. I would also like to respond to the point that both you and Matthew made about the RIPE NCC taking a more liberal approach in our interpretation. There is a balance to be struck here, between allowing for corner cases, and the requirements being clearly listed and adhered to. Our understanding in the impact analysis is based both on our previous experience with IPv6 requests and our interpretation of the policy text. If the community would like us to take a more liberal approach, we will need some additional guidelines on how to evaluate the requests in the proposed policy text. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 24/07/15 13:31, Silvia Hagen wrote: > > Hi to all > > +1 > > I fully support this proposal. I believe it is an important step to > allow for useful deployment of IPv6 taking advantage of the advanced > and extended IPv6 address architecture. > > Responding to the request for feedback on the "RIPE understanding" > section here are some thoughts and comments: > > -The overall tone of the "understanding" section still sounds more > like "our main goal is to preserve addresses" instead of "let's make > generous use oft he extended address architecture and available space" > to me. > > It is not easy to step out of IPv4 thinking. While we all know in our > minds that we need to do this, implementing it is much more difficult. > (I am for instance referring to this sentence, which appears more than > once: " The RIPE NCC will ask for additional documentation to justify > why a less address consuming hierarchy or topology can not be > implemented."). > > There is a widely adopted rule that all address conservation > mechanisms should be removed from IPv6 address plans. > > -There is one point where I have a problem to understand, maybe I am > misinterpreting the statement. It says " The RIPE NCC will consider > longevity reasonable for a similar timeframe for which past growth was > documented." - So my question is: how does this accomodate startups? > We are moving into the age of the Internet of Things. We expect new > technologies and services to spring up, not foreseeable. This includes > new business models and opportunities for new companies that have no > history. > > -The policy for subsequent allocations will have to be updated > accordingly if this policy is accepted. > > -Quote: "If this network topology is justified, the RIPE NCC will > consider up to one extra bit per hierarchical level or geographical > segment as reasonable, on top of the documented need for that part of > the network." > Comment: how about "generally up to one bit" - leave room for exceptions. > > -The rules seem quite complicated and a bit hard to really understand > and correctly apply to me. I wonder how easy it will be to assess > requests based on this. > > As mentioned already, I believe this proposal is a good step. When it > comes to how to apply it, I feel there is a lot of "strictness" in the > wording. It is always nice to have clear and strict rules, everyone > can easily apply them. But reality is different. There is no good rule > without exceptions and I hope that this policy will be applied with > common sense and adjusted to reality. > > And my personal viewpoint is, that we should not restrict IPv6 address > plans from the beginning. Our main target should be to finally DEPLOY > it as broadly as possible and have ease of operation as a main goal. > That is what the address architecture provides. > > By today we have given out the equivalent of 171'000 /32 of the > currently defined global unicast space (2000::/3) (according to > Bgpexpert ) and this > equals 0.032%. Hey that is 171'000 times more than the whole current > Internet and we are at 0.032%! I think we should apply a generous > allocation model that makes it easy to deploy, operate, secure?.. > > ?and if we get to the point where we feel we have been too generous, > we can still adjust policies and become more careful. Once we have > used 2000::/3 we still have 7 more chances to do better. We could even > define a re-assessment once we are 30% or 50% into the 2000::/3. > > My two cents, greetings from the summer heat > > Silvia Hagen > > Chair Swiss IPv6 Council > > -----Urspr?ngliche Nachricht----- > Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im > Auftrag von Marco Schmidt > Gesendet: Donnerstag, 9. Juli 2015 14:20 > An: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Betreff: [address-policy-wg] 2015-03 New Draft Document and Impact > Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2015-03, > "Assessment Criteria for IPv6 Initial Allocation Size", has now been > published, along with an impact analysis conducted by the RIPE NCC. > > The proposal aims to expand the criteria for evaluating initial > > IPv6 allocations larger than a /29. The RIPE NCC would consider > additional aspects beyond only the number of existing users and extent > of the organisation's infrastructure. > > Some of the differences from version 1.0 include: > > - Introduction of new assessment criteria used to evaluate IPv6 > allocations larger than a /29 > > - Related wording adjustments in the summary and rationale of the proposal > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2015-03 > > and the draft document at: > > https://www.ripe.net/participate/policies/proposals/2015-03/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net > before 7 August 2015. > > Regards > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > Sunny Connection AG > > CH-8124 Maur > > +41 (0)44 887 62 10 > > www.sunny.ch > > http://twitter.com/sunny_shagen > > ****************************************** > > IPv6 Business Conference, June 18, 2015, Zurich > __ > > International Top Speakers, Unique Program > > Great Networking - *watch out for the 2016 Conference* > > ****************************************** > > Switzerland is in the Top 5 in IPv6 User Adoption > > We reached 21% in June 2015! > > *********************************** > > Our website is dual-stack ? how about yours? > > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mathew.Newton643 at official.mod.uk Mon Jul 27 16:53:10 2015 From: Mathew.Newton643 at official.mod.uk (Mathew Newton) Date: Mon, 27 Jul 2015 14:53:10 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <55B639B7.8090604@ripe.net> References: <55B639B7.8090604@ripe.net> Message-ID: Hi Marco, > I would also like to respond to the point that both you and Matthew made about the RIPE NCC taking a more liberal approach in our interpretation. > There is a balance to be struck here, between allowing for corner cases, and the requirements being clearly listed and adhered to. Our understanding > in the impact analysis is based both on our previous experience with IPv6 requests and our interpretation of the policy text. If the community would > like us to take a more liberal approach, we will need some additional guidelines on how to evaluate the requests in the proposed policy text. Perhaps this is where the difficulty lies... A liberal approach generally presupposes the absence of rules and/or precise definition and so trying to put specifics into policy to promote such an approach may be counter-productive. On that basis I think I'd prefer not to see the proposed policy text containing even more detail than it does now. I guess this is where the Impact Analysis, and its publication, plays such a key role - it helps form a common understanding between RIPE NCC and the community as to how the policy can/will be implemented without requiring the policy text to be so specific. Taking this a step further it can also allow for a pragmatic approach to be taken where necessary and appropriate i.e. it captures the spirit of the law as opposed to the letter. Mathew From office at ip4market.ru Mon Jul 27 18:10:30 2015 From: office at ip4market.ru (Staff) Date: Mon, 27 Jul 2015 19:10:30 +0300 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: References: Message-ID: <55B657F6.8000409@ip4market.ru> Sorry new message on 2015-01. No consensus was reached. Even on RIPE website information that nothing interesting and good in that proposal https://www.ripe.net/participate/policies/proposals/2015-01 --- After analyzing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. --- But everybody here just understood that nobody listen to them. Yes. It's good idea to submit new policy canceling this one policy or making it better! But if nobody listen to members why to do so? Yuri at ip4market On 26.07.2015 19:43, Sander Steffann wrote: > Hello David, > >> Hello, The allocations made before the date of this announcement, should be governed by the old politics. > > The *transfers* made before the date of the announcement are handled by the old transfer policies, transfers made after that are made according to the new policy. The date the allocation was made is not relevant to determining which transfer policy is applied. > > Please stop discussing 2015-01 and its implementation. We have reached consensus and the policy has been implemented. If you want to change anything please submit a new policy proposal. > > Cheers, > Sander > > From garry at nethinks.com Mon Jul 27 18:34:00 2015 From: garry at nethinks.com (Garry Glendown) Date: Mon, 27 Jul 2015 18:34:00 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <55B657F6.8000409@ip4market.ru> References: <55B657F6.8000409@ip4market.ru> Message-ID: <55B65D78.4030802@nethinks.com> > But everybody here just understood that nobody listen to them. > Yes. It's good idea to submit new policy canceling this one policy or > making it better! But if nobody listen to members why to do so? Democracy sucks sometimes... unfortunately, most participants in the list weighed the arguments and were in support of the policy change - and considering the wailing done by several people who make money by trading IPs, it may be a first successful step towards abuse of the policies for IP address transfer ... I reckon we can get the additional loopholes fixed in the next proposal - and I doubt they will turn out to reverse the change ... -garry From sander at steffann.nl Mon Jul 27 20:08:51 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 27 Jul 2015 20:08:51 +0200 Subject: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) In-Reply-To: <55B657F6.8000409@ip4market.ru> References: <55B657F6.8000409@ip4market.ru> Message-ID: Hello Yuri, > No consensus was reached. Yes there was. I declared so a few days ago. If you truly believe that my decision to do that was wrong then please follow the Appeals procedure described in section 4 of our PDP (https://www.ripe.net/publications/docs/ripe-642) but please stop repeating yourself on this mailing list. Cheers, Sander PS: my apologies for repeating myself, but I want to make sure that everybody understands how this works so that we (the chairs) don't get blamed over and over again for not listening to the community. We do listen, and we do make honest decisions, and we will fully cooperate with any appeals procedure if people feel we wronged them. PPS: sorry for a PS section that is longer than the main content From silvia.hagen at sunny.ch Tue Jul 28 21:25:21 2015 From: silvia.hagen at sunny.ch (Silvia Hagen) Date: Tue, 28 Jul 2015 19:25:21 +0000 Subject: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <55B639B7.8090604@ripe.net> References: <55B639B7.8090604@ripe.net> Message-ID: Hi Marco Startups: If you have an approach that works well, cool! A startup can have big plans and have success or fail or have to scale down substantially, there is always a risk. But we never know in advance. If you have a policy that works well, thats good. Probably the point will be to "reserve" enough space in case they turn into the next Google or FB (in size) :) Liberal approach: To me, liberal means no too strict rules. You can define as many rules as you want, you will never be able to catch and cover all possible corner cases with it. We (community) cannot give absolution to any decision you make by writing guidelines that do so either. My personal stance is: I trust you RIPE people to understand the issues, the market, the IPv6 addressing architecture and requirements well enough to make informed, balanced and fair decisions that support deployment of IPv6 when assessing requests. I think we are all good to go as it is. Silvia Von: Marco Schmidt [mailto:mschmidt at ripe.net] Gesendet: Montag, 27. Juli 2015 16:01 An: Silvia Hagen; address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Hi Silvia, Thanks for your feedback on our understanding of the policy. Regarding your point about start-ups - it can be difficult to make a fair evaluation on what is often a vague estimate of potential growth, and so the tendency here is to be somewhat cautious. On the other hand, we feel that our approach under the existing policy has been working well, and we have never had any issues or complaints from start-ups in the past. I would also like to respond to the point that both you and Matthew made about the RIPE NCC taking a more liberal approach in our interpretation. There is a balance to be struck here, between allowing for corner cases, and the requirements being clearly listed and adhered to. Our understanding in the impact analysis is based both on our previous experience with IPv6 requests and our interpretation of the policy text. If the community would like us to take a more liberal approach, we will need some additional guidelines on how to evaluate the requests in the proposed policy text. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 24/07/15 13:31, Silvia Hagen wrote: Hi to all +1 I fully support this proposal. I believe it is an important step to allow for useful deployment of IPv6 taking advantage of the advanced and extended IPv6 address architecture. Responding to the request for feedback on the "RIPE understanding" section here are some thoughts and comments: - The overall tone of the "understanding" section still sounds more like "our main goal is to preserve addresses" instead of "let's make generous use oft he extended address architecture and available space" to me. It is not easy to step out of IPv4 thinking. While we all know in our minds that we need to do this, implementing it is much more difficult. (I am for instance referring to this sentence, which appears more than once: " The RIPE NCC will ask for additional documentation to justify why a less address consuming hierarchy or topology can not be implemented."). There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans. - There is one point where I have a problem to understand, maybe I am misinterpreting the statement. It says " The RIPE NCC will consider longevity reasonable for a similar timeframe for which past growth was documented." - So my question is: how does this accomodate startups? We are moving into the age of the Internet of Things. We expect new technologies and services to spring up, not foreseeable. This includes new business models and opportunities for new companies that have no history. - The policy for subsequent allocations will have to be updated accordingly if this policy is accepted. - Quote: "If this network topology is justified, the RIPE NCC will consider up to one extra bit per hierarchical level or geographical segment as reasonable, on top of the documented need for that part of the network." Comment: how about "generally up to one bit" - leave room for exceptions. - The rules seem quite complicated and a bit hard to really understand and correctly apply to me. I wonder how easy it will be to assess requests based on this. As mentioned already, I believe this proposal is a good step. When it comes to how to apply it, I feel there is a lot of "strictness" in the wording. It is always nice to have clear and strict rules, everyone can easily apply them. But reality is different. There is no good rule without exceptions and I hope that this policy will be applied with common sense and adjusted to reality. And my personal viewpoint is, that we should not restrict IPv6 address plans from the beginning. Our main target should be to finally DEPLOY it as broadly as possible and have ease of operation as a main goal. That is what the address architecture provides. By today we have given out the equivalent of 171'000 /32 of the currently defined global unicast space (2000::/3) (according to Bgpexpert) and this equals 0.032%. Hey that is 171'000 times more than the whole current Internet and we are at 0.032%! I think we should apply a generous allocation model that makes it easy to deploy, operate, secure..... ...and if we get to the point where we feel we have been too generous, we can still adjust policies and become more careful. Once we have used 2000::/3 we still have 7 more chances to do better. We could even define a re-assessment once we are 30% or 50% into the 2000::/3. My two cents, greetings from the summer heat Silvia Hagen Chair Swiss IPv6 Council -----Urspr?ngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 9. Juli 2015 14:20 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC Sunny Connection AG CH-8124 Maur +41 (0)44 887 62 10 www.sunny.ch http://twitter.com/sunny_shagen ****************************************** IPv6 Business Conference, June 18, 2015, Zurich International Top Speakers, Unique Program Great Networking - watch out for the 2016 Conference ****************************************** Switzerland is in the Top 5 in IPv6 User Adoption We reached 21% in June 2015! *********************************** Our website is dual-stack - how about yours? *********************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: