From mir at ripe.net Fri Feb 1 15:09:58 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 01 Feb 2013 15:09:58 +0100 Subject: [address-policy-wg] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 Message-ID: <510BCCB6.1060309@ripe.net> [apologies for duplicates] Dear colleagues, We allocated the 1,000th /22 from the last /8. Please read more on RIPE Labs: https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8 Kind regards, Mirjam Kuehne RIPE NCC From erik at bais.name Mon Feb 4 12:48:21 2013 From: erik at bais.name (Erik Bais) Date: Mon, 4 Feb 2013 11:48:21 +0000 Subject: [address-policy-wg] Status of Policy Proposal 2012-04 - PI Assignments from the last /8 Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C204CC13B@e2010-mbx-c1n1.exchange2010.nl> Hi, Is there any news on this proposal yet ? https://www.ripe.net/ripe/policies/proposals/2012-04 I would like to see this proposal binned rather today than tomorrow. No disrespect to Nick for putting this in writing and bringing this discussion in front of us, but opening the gates will not solve the problems most companies face, if they notice IPv4 shortage... Especially since it will only delay their pain for a very short period. And the problems for new entries (after that short period) for not having v4 available in the (not too far) future for NAT64 or alike technologies weigh much higher imho than providing cheap PI resources. So in short, I don't support this policy and I would like to have this archived for future references asap. Kind regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Feb 4 13:33:09 2013 From: gert at space.net (Gert Doering) Date: Mon, 4 Feb 2013 13:33:09 +0100 Subject: [address-policy-wg] Status of Policy Proposal 2012-04 - PI Assignments from the last /8 In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204CC13B@e2010-mbx-c1n1.exchange2010.nl> References: <862A73D42343AE49B2FC3C32FDDFE91C204CC13B@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <20130204123309.GD51699@Space.Net> Hi, On Mon, Feb 04, 2013 at 11:48:21AM +0000, Erik Bais wrote: > https://www.ripe.net/ripe/policies/proposals/2012-04 It's waiting for the proposer (Nick) to come up with a new version of the text, as it was clear that the current version can not reach consensus, but at the same time the WG acknowledged that there is "an issue" that we might need to handle. > So in short, I don't support this policy and I would like to have this archived for future references asap. We hear you. (Still, if Nick decides to come up with a new revision that is fundamentally different, you'd need to re-state your opposition to make clear that it still applies) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shane at time-travellers.org Mon Feb 4 14:13:20 2013 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 4 Feb 2013 14:13:20 +0100 Subject: [address-policy-wg] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <510BCCB6.1060309@ripe.net> References: <510BCCB6.1060309@ripe.net> Message-ID: <20130204141320.128f8bfe@shane-desktop> All, On Friday, 2013-02-01 15:09:58 +0100, Mirjam Kuehne wrote: > We allocated the 1,000th /22 from the last /8. Please read more on > RIPE Labs: > > https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8 Just so I understand... It took 140 days to allocate 1000 addresses, or about 7.14 address per day. There are 2^14 /22 in a /8, or 16384. At that burn rate, it will take about 2150 days to finish out the last /8. (16384 - 1000) / 7.14 = 2155 That's about 6 years, assuming things stay constant. 2155 / 365.25 = 5.9 Based on Google's numbers, IPv6 has roughly doubled as a percentage of traffic for the last 3 years... if this continues for the next 6 years, we'll have about 70% of traffic over IPv6 when the RIPE NCC really, REALLY runs out of IPv4 in this region. (Of course, if it continues for 7 years then 140% of traffic will be over IPv6.) ;) It looks like there's likely to be a window of time where new entrants won't be able to get any IPv4 space, and a significant percentage of users will still be IPv4-only. Should we tweak the policy now to make it harder to get IPv4 address space, or wait a few years? It seems slightly unfair to future entrants, but the whole IPv4 allocation model has always vastly favored early entrants, so perhaps we shouldn't worry about it yet. Cheers, -- Shane From info at leadertelecom.ru Tue Feb 5 11:11:35 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 5 Feb 2013 14:11:35 +0400 Subject: [address-policy-wg] [Ticket#2013020401002158] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <20130204141320.128f8bfe@shane-desktop> References: <20130204141320.128f8bfe@shane-desktop><510BCCB6.1060309@ripe.net> Message-ID: <1360059093.931764.13650409.276659.2@otrs.hostingconsult.ru> Dear?Shane, >?? That's about 6 years, assuming things stay constant. > ? ? ? 2155 / 365.25 = 5.9 Many companies in fact had reserves, while they thinked about future. I think the most intresting changes we will see during next 12 month. Amount of requests IPv4 from last /8 can rapidly increase (in 2-5 times).? ? -- Alexey Ivanov LeaderTelecom? 04.02.2013 18:02 - Shane Kerr ???????(?): All, On Friday, 2013-02-01 15:09:58 +0100, Mirjam Kuehne wrote: > We allocated the 1,000th /22 from the last /8. Please read more on > RIPE Labs: > > [1]https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-sla[..] Just so I understand... ??It took 140 days to allocate 1000 addresses, or about 7.14 address ??per day. ??There are 2^14 /22 in a /8, or 16384. ??At that burn rate, it will take about 2150 days to finish out the ??last /8. ??????(16384 - 1000) / 7.14 = 2155 ??That's about 6 years, assuming things stay constant. ??????2155 / 365.25 = 5.9 Based on Google's numbers, IPv6 has roughly doubled as a percentage of traffic for the last 3 years... if this continues for the next 6 years, we'll have about 70% of traffic over IPv6 when the RIPE NCC really, REALLY runs out of IPv4 in this region. (Of course, if it continues for 7 years then 140% of traffic will be over IPv6.) ;) It looks like there's likely to be a window of time where new entrants won't be able to get any IPv4 space, and a significant percentage of users will still be IPv4-only. Should we tweak the policy now to make it harder to get IPv4 address space, or wait a few years? It seems slightly unfair to future entrants, but the whole IPv4 allocation model has always vastly favored early entrants, so perhaps we shouldn't worry about it yet. Cheers, -- Shane ? [1] https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Tue Feb 5 17:21:51 2013 From: nigel at titley.com (Nigel Titley) Date: Tue, 05 Feb 2013 16:21:51 +0000 Subject: [address-policy-wg] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <20130204141320.128f8bfe@shane-desktop> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> Message-ID: <5111319F.4040909@titley.com> On 04/02/2013 13:13, Shane Kerr wrote: > All, > > On Friday, 2013-02-01 15:09:58 +0100, > Mirjam Kuehne wrote: >> We allocated the 1,000th /22 from the last /8. Please read more on >> RIPE Labs: >> >> https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8 > Just so I understand... > > It took 140 days to allocate 1000 addresses, or about 7.14 address > per day. > > There are 2^14 /22 in a /8, or 16384. > > At that burn rate, it will take about 2150 days to finish out the > last /8. > (16384 - 1000) / 7.14 = 2155 > > That's about 6 years, assuming things stay constant. > 2155 / 365.25 = 5.9 > > Based on Google's numbers, IPv6 has roughly doubled as a percentage of > traffic for the last 3 years... if this continues for the next 6 years, > we'll have about 70% of traffic over IPv6 when the RIPE NCC really, > REALLY runs out of IPv4 in this region. (Of course, if it continues for > 7 years then 140% of traffic will be over IPv6.) ;) > > It looks like there's likely to be a window of time where new entrants > won't be able to get any IPv4 space, and a significant percentage of > users will still be IPv4-only. > > Should we tweak the policy now to make it harder to get IPv4 address > space, or wait a few years? It seems slightly unfair to future entrants, > but the whole IPv4 allocation model has always vastly favored early > entrants, so perhaps we shouldn't worry about it yet. > Deckchairs... deckchairs... Nigel From shane at time-travellers.org Wed Feb 6 13:47:21 2013 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 6 Feb 2013 13:47:21 +0100 Subject: [address-policy-wg] [Ticket#2013020401002158] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <1360059093.931764.13650409.276659.2@otrs.hostingconsult.ru> References: <20130204141320.128f8bfe@shane-desktop> <510BCCB6.1060309@ripe.net> <1360059093.931764.13650409.276659.2@otrs.hostingconsult.ru> Message-ID: <20130206134721.41938e7f@shane-desktop> Alexey, On Tuesday, 2013-02-05 14:11:35 +0400, LeaderTelecom Ltd. wrote: > Dear?Shane, > > >?? That's about 6 years, assuming things stay constant. > > ? ? ? 2155 / 365.25 = 5.9 > > Many companies in fact had reserves, while they thinked about future. But I thought the whole point of the special policy for the last /8 was to support new companies, who did not have a chance to get any reserves? To me, the policy makes no sense otherwise. > I think the most intresting changes we will see during next 12 month. > Amount of requests IPv4 from last /8 can rapidly increase (in 2-5 > times). We see a spike in the number of new LIR which happened almost exactly at the same time the IPv4 addresses ran out and the "one allocation per new LIR" policy went into effect: https://labs.ripe.net/statistics/lirs-with-and-without-ipv6 It looks like people are creating new LIR to circumvent the intent of the policy - reserving IPv4 space for newcomers. Cheers, -- Shane From shane at time-travellers.org Wed Feb 6 13:58:23 2013 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 6 Feb 2013 13:58:23 +0100 Subject: [address-policy-wg] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <5111319F.4040909@titley.com> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> Message-ID: <20130206135823.69e3e88f@shane-desktop> Nigel, On Tuesday, 2013-02-05 16:21:51 +0000, Nigel Titley wrote: > > Should we tweak the policy now to make it harder to get IPv4 address > > space, or wait a few years? It seems slightly unfair to future > > entrants, but the whole IPv4 allocation model has always vastly > > favored early entrants, so perhaps we shouldn't worry about it yet. > > > Deckchairs... deckchairs... Do we care about allowing new entrants or not? If we don't, then we should scrap the last /8 policy, give the entire block out in one big allocation to MyHugeTelco.tld and be done with it. If we do, then we should try to make sure that the policy actually works. I admit to looking at a very short period of time, but it looks like new companies are not going to have any options for IPv4 space in a few years. IPv4 allocation policy tweaks do seem mostly pointless, but they won't be pointless to the start-up founded 4 or 5 years from now, who is trying to connect to IPv4-only users. And who knows, maybe that start-up will be the next Google or Wikipedia, and it will matter to the rest of us too if they succeed or not.... Cheers, -- Shane From info at leadertelecom.ru Wed Feb 6 14:09:57 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Wed, 6 Feb 2013 17:09:57 +0400 Subject: [address-policy-wg] [Ticket#2013020401002158] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <20130206134721.41938e7f@shane-desktop> References: <20130206134721.41938e7f@shane-desktop><20130204141320.128f8bfe@shane-desktop> <510BCCB6.1060309@ripe.net> <1360059093.931764.13650409.276659.2@otrs.hostingconsult.ru> Message-ID: <1360156196.420239.226513801.276659.2@otrs.hostingconsult.ru> Dear?Shane, > But I thought the whole point of the special policy for the last /8 was > to support new companies, who did not have a chance to get any reserves? Correct.? I see 2 cases: 1. "Old LIRs". They had some IP-space from previos /8. They had some IPs. And have some networks which were used not very accurate. They can optimize using IPv4 and didn't request IPv4 from last /24. They can give some IPs for clients. But I belive 80% of them will request IPv4 from last /8 during 12 month. 2. "New LIRs". Many "Old LIRs" tell to customers that they can give only 1-4 IPs. So in this case companies which need IPs will request them via RIPE as a new LIRs.? I think we should push deployment IPv6 and forget about any improvments policy for IPv4.? -- Alexey LeaderTelecom 06.02.2013 16:53 - Shane Kerr ???????(?): Alexey, On Tuesday, 2013-02-05 14:11:35 +0400, LeaderTelecom Ltd. wrote: > Dear?Shane, > > >?? That's about 6 years, assuming things stay constant. > > ? ? ? 2155 / 365.25 = 5.9 >?? > Many companies in fact had reserves, while they thinked about future. But I thought the whole point of the special policy for the last /8 was to support new companies, who did not have a chance to get any reserves? To me, the policy makes no sense otherwise. > I think the most intresting changes we will see during next 12 month. > Amount of requests IPv4 from last /8 can rapidly increase (in 2-5 > times). We see a spike in the number of new LIR which happened almost exactly at the same time the IPv4 addresses ran out and the "one allocation per new LIR" policy went into effect: [1]https://labs.ripe.net/statistics/lirs-with-and-without-ipv6 It looks like people are creating new LIR to circumvent the intent of the policy - reserving IPv4 space for newcomers. Cheers, -- Shane [1] https://labs.ripe.net/statistics/lirs-with-and-without-ipv6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Feb 6 14:09:59 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 06 Feb 2013 14:09:59 +0100 Subject: [address-policy-wg] New on RIPE Labs: 1, 000 /22 Allocated from Last /8 In-Reply-To: <20130206135823.69e3e88f@shane-desktop> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> Message-ID: <51125627.8090405@fud.no> * Shane Kerr > On Tuesday, 2013-02-05 16:21:51 +0000, > Nigel Titley wrote: >>> Should we tweak the policy now to make it harder to get IPv4 address >>> space, or wait a few years? It seems slightly unfair to future >>> entrants, but the whole IPv4 allocation model has always vastly >>> favored early entrants, so perhaps we shouldn't worry about it yet. >>> >> Deckchairs... deckchairs... > > Do we care about allowing new entrants or not? > > If we don't, then we should scrap the last /8 policy, give the entire > block out in one big allocation to MyHugeTelco.tld and be done with it. > > If we do, then we should try to make sure that the policy actually > works. I admit to looking at a very short period of time, but it looks > like new companies are not going to have any options for IPv4 space in > a few years. > > IPv4 allocation policy tweaks do seem mostly pointless, but they won't > be pointless to the start-up founded 4 or 5 years from now, who is > trying to connect to IPv4-only users. And who knows, maybe that > start-up will be the next Google or Wikipedia, and it will matter to > the rest of us too if they succeed or not.... I'm not sure I follow the argument here. Wouldn't making it harder to obtain a ?last /8? IPv4 block increase the likelihood of your ?next Google? failing, because they couldn't obtain the IPv4 space they needed to be successful? -- Tore Anderson From jim at rfc1035.com Wed Feb 6 15:08:22 2013 From: jim at rfc1035.com (Jim Reid) Date: Wed, 6 Feb 2013 14:08:22 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <20130206135823.69e3e88f@shane-desktop> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> Message-ID: <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> On 6 Feb 2013, at 12:58, Shane Kerr wrote: > Do we care about allowing new entrants or not? Yeah, but there are limits. I hope/expect our grandchildren won't be discussing 60-70 years from now how future LIRs can qualify for a /32 of v4 or make the remaining RIR reserves ov v4 last beyond the heat death of the universe. :-) At some point v4 simply will run out and no amount of policy tweaking is going to change that. The current trends/policy suggest the NCC has 5-6 years to go. Seems about right. Of course if there's evidence of abuse or LIRs gaming the system, that needs to be dealt with. Do you have data which suggests bad things are happening? FWIW the issue I think we should be discussing is what role, if any, the RIRs have when/if the market in v4 goes mainstream. Debating how we might make the dregs of v4 space last a little bit longer does seem to me to be like rearranging the deckchairs on the Titanic after the iceberg hit. From erik at bais.name Wed Feb 6 15:32:33 2013 From: erik at bais.name (Erik Bais) Date: Wed, 6 Feb 2013 14:32:33 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> > Debating how we might make the dregs of v4 space last a little bit longer does seem to me to be like rearranging the deckchairs on the Titanic after the iceberg hit. Having a deckchair or not, might become a topic if you see there is no room left on the lifeboats and you are looking for a floatation device ... presuming that they deckchairs are made from wood and will float .. Or if you want to do the sit and wait game, while everyone else is in panic and jumps. Anyway .. back to the topic .. If we are actually 'care about allowing new entrants', there might be another topic to look into which isn't covered in the current policy for the final /8. And that is the fact that it is allowed to merge LIR's that have been assigned an allocation from the final /8. Currently there are already 6 LIR's to my knowledge that have been merged that now have 2 or more 185.x.y.z /22's ... I've been hearing several discussions in the grapevines from parties that are already low on IP space to use that loop-hole to setup new LIR's, merge them and repeat. To me, I think that we should cut off this route asap, otherwise we might as well hand out the final /8 as if any other /8 .. and be done with it ... Btw.. anyone in need of a deckchair ? Just bring some whiskey and cigars .. let's sit down and watch the show unfold. Regards, Erik Bais From marcin at leon.pl Wed Feb 6 15:43:56 2013 From: marcin at leon.pl (Marcin Kuczera) Date: Wed, 06 Feb 2013 15:43:56 +0100 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <51126C2C.3010806@leon.pl> On 2013-02-06 15:32, Erik Bais wrote: >> Debating how we might make the dregs of v4 space last a little bit longer does seem to me to be like rearranging the deckchairs on the Titanic after the iceberg hit. > Having a deckchair or not, might become a topic if you see there is no room left on the lifeboats and you are looking for a floatation device ... presuming that they deckchairs are made from wood and will float .. > Or if you want to do the sit and wait game, while everyone else is in panic and jumps. > > Anyway .. back to the topic .. > > If we are actually 'care about allowing new entrants', there might be another topic to look into which isn't covered in the current policy for the final /8. > > And that is the fact that it is allowed to merge LIR's that have been assigned an allocation from the final /8. > > Currently there are already 6 LIR's to my knowledge that have been merged that now have 2 or more 185.x.y.z /22's ... > I've been hearing several discussions in the grapevines from parties that are already low on IP space to use that loop-hole to setup new LIR's, merge them and repeat. > > To me, I think that we should cut off this route asap, otherwise we might as well hand out the final /8 as if any other /8 .. and be done with it ... There will be allways such possibility, even if you say that LIRs that are closed shorter than i.e. 5 years after creation have to return addresses - this might be still cheaper to pay 1,8keuro/year than to buy addresses on market. 2keuro + 1.8euro/4 (just one quarter) = 2450 euro for 1024 IP = 2.4 euro per IP. Market price varies from 20$ to 10$ (depending on prefix size, smaller - more expansive). So maybe 5 years blocking period is a good idea as this will be allways money case ? Regards, Marcin > > Btw.. anyone in need of a deckchair ? Just bring some whiskey and cigars .. let's sit down and watch the show unfold. > > Regards, > Erik Bais > From nick at inex.ie Wed Feb 6 15:56:42 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 14:56:42 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <51126F2A.7010008@inex.ie> On 06/02/2013 14:32, Erik Bais wrote: > To me, I think that we should cut off this route asap, otherwise we > might as well hand out the final /8 as if any other /8 .. and be done > with it ... If you're planning to close all of the potential avenue of abuse starting with this one, then let me grab me a chair and some popcorn - I will thoroughly enjoy the hilarious entertainment which will ensue. Nick From jan at go6.si Wed Feb 6 16:32:13 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 06 Feb 2013 10:32:13 -0500 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <51126F2A.7010008@inex.ie> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> <51126F2A.7010008@inex.ie> Message-ID: <5112777D.6010607@go6.si> On 2/6/13 9:56 AM, Nick Hilliard wrote: > On 06/02/2013 14:32, Erik Bais wrote: >> To me, I think that we should cut off this route asap, otherwise we >> might as well hand out the final /8 as if any other /8 .. and be done >> with it ... > > If you're planning to close all of the potential avenue of abuse starting > with this one, then let me grab me a chair and some popcorn - I will > thoroughly enjoy the hilarious entertainment which will ensue. I was just about to say the same thing. Save a chair and some popcorn for me ;) No matter how much policy we do, there is probably no way to outsmart the desperate IPv4-hungry folx in huge need of additional addresses. Cheers, Jan From gert at space.net Wed Feb 6 19:38:10 2013 From: gert at space.net (Gert Doering) Date: Wed, 6 Feb 2013 19:38:10 +0100 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <5112777D.6010607@go6.si> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> <51126F2A.7010008@inex.ie> <5112777D.6010607@go6.si> Message-ID: <20130206183810.GZ51699@Space.Net> Hi, On Wed, Feb 06, 2013 at 10:32:13AM -0500, Jan Zorz @ go6.si wrote: > I was just about to say the same thing. Save a chair and some popcorn > for me ;) So how much time do we need for this in Dublin? I'll ask the NCC to provide Popcorn... (No, that was a *joke*, in case someone's sarcasm detector is not turned on). I am listening to the debate, but so far, I more agree with Nick and Jan that people are likely to find loopholes around this, no matter what we do. Tie it to "one LIR one block"? OK, I'll just keep the LIRs around, then. Tie it to "one LIR per person"? OK, I'll find some strawman to be "the LIR admin-c and tech-c". "Make it hideously expensive?" - bad for new entrants, mission failed... So unless someone more creative than I comes up with a good idea what could be done (and finds some backing on the list), I don't think it will be very useful to spend large amounts of precious face-to-face time on this. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From jan at go6.si Wed Feb 6 21:06:16 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 06 Feb 2013 15:06:16 -0500 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <20130206183810.GZ51699@Space.Net> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> <51126F2A.7010008@inex.ie> <5112777D.6010607@go6.si> <20130206183810.GZ51699@Space.Net> Message-ID: <5112B7B8.40206@go6.si> On 2/6/13 1:38 PM, Gert Doering wrote: > So unless someone more creative than I comes up with a good idea what > could be done (and finds some backing on the list), I don't think it > will be very useful to spend large amounts of precious face-to-face time > on this. This is like trying to keep the water not rolling down the hill... It will eventually find it's way down anyway, so probably it is better to dig a channels to keep it where you want it ;) Cheers, Jan From mueller at syr.edu Wed Feb 6 20:38:01 2013 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 6 Feb 2013 19:38:01 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <855077AC3D7A7147A7570370CA01ECD232D71F@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > > it is allowed to merge LIR's that have been assigned > an allocation from the final /8. > > I've been hearing several discussions in the grapevines from parties that are > already low on IP space to use that loop-hole to setup new LIR's, merge them > and repeat. What if there are legitimate reasons to merge smaller LIRs? I don't see any way to attack this without creating more costly enforcement issues and needless forms of categorizing and regulating LIRs. > To me, I think that we should cut off this route asap, otherwise we might as > well hand out the final /8 as if any other /8 .. and be done with it ... That is not such a bad option, really. New entrants could acquire them in the secondary market anyway, or from brokers or leases. And if you're a v6 evangelist, the sooner the remaining v4s are vacuumed up, the better, no? But it may be that the status quo is the optimal middle ground. Perhaps 1/4 of the /22s are actually given to the intended type of recipient, it's better than nothing. > Btw.. anyone in need of a deckchair ? Just bring some whiskey and cigars .. And a brass band! And Kate Winslet!! But why the metaphor of a sinking ship? The v4 internet is not sinking, it's just becoming more efficient. From nick at inex.ie Wed Feb 6 21:23:52 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 20:23:52 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <20130206183810.GZ51699@Space.Net> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> <51126F2A.7010008@inex.ie> <5112777D.6010607@go6.si> <20130206183810.GZ51699@Space.Net> Message-ID: <5112BBD8.8010900@inex.ie> On 06/02/2013 18:38, Gert Doering wrote: > So unless someone more creative than I comes up with a good idea what > could be done (and finds some backing on the list), I don't think it > will be very useful to spend large amounts of precious face-to-face time > on this. I'd be happy to provide popcorn. Anyone got a couch we can all sit on? Nick From brian.nisbet at heanet.ie Wed Feb 6 21:42:52 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 06 Feb 2013 20:42:52 +0000 Subject: [address-policy-wg] saving v4 space for new entrants In-Reply-To: <5112BBD8.8010900@inex.ie> References: <510BCCB6.1060309@ripe.net> <20130204141320.128f8bfe@shane-desktop> <5111319F.4040909@titley.com> <20130206135823.69e3e88f@shane-desktop> <36E26AC0-D164-41A6-AE2E-48A6FFF66403@rfc1035.com> <862A73D42343AE49B2FC3C32FDDFE91C204CCC1D@e2010-mbx-c1n1.exchange2010.nl> <51126F2A.7010008@inex.ie> <5112777D.6010607@go6.si> <20130206183810.GZ51699@Space.Net> <5112BBD8.8010900@inex.ie> Message-ID: <5112C04C.2070600@heanet.ie> On 06/02/2013 20:23, Nick Hilliard wrote: > On 06/02/2013 18:38, Gert Doering wrote: >> So unless someone more creative than I comes up with a good idea what >> could be done (and finds some backing on the list), I don't think it >> will be very useful to spend large amounts of precious face-to-face time >> on this. > > I'd be happy to provide popcorn. Anyone got a couch we can all sit on? I have a couch in Dublin, but it's not big enough for the entire WG... We could ask the hotel to import some specially? :) Brian From emadaio at ripe.net Mon Feb 11 14:54:07 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 11 Feb 2013 14:54:07 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) Message-ID: Dear Colleagues, The draft document for the proposal described in 2012-10 has been published. The impact analysis that was conducted for this proposal has also been published You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-10 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-10/draft We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 11 March 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Tue Feb 12 15:55:30 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 12 Feb 2013 15:55:30 +0100 Subject: [address-policy-wg] 2012-05 Proposal Accepted (Transparency in Address Block Transfers) Message-ID: Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-553, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-05 The updated RIPE document is ripe-577 and is available at: https://www.ripe.net/ripe/docs/ripe-577 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From lists-ripe at c4inet.net Wed Feb 13 13:04:41 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 13 Feb 2013 12:04:41 +0000 Subject: [address-policy-wg] 2012-05 Proposal Accepted - Request for Clarification In-Reply-To: References: Message-ID: <20130213120441.GA5418@cilantro.c4inet.net> Hi, On Tue, Feb 12, 2013 at 03:55:30PM +0100, Emilio Madaio wrote: >The updated RIPE document is ripe-577 and is available at: > >https://www.ripe.net/ripe/docs/ripe-577 ripe-577 contains, in S5.5 the sentence: "Re-allocated blocks will be signed to establish the current allocation owner." What does this refer to? Does this mean these blocks will *mandatorily* be signed with a RPKI certificate and, if yes, how does that square with the NCC's stated policy that RPKI certs will always be voluntary? Regards, Sascha Luck From rogerj at gmail.com Wed Feb 13 20:51:44 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 13 Feb 2013 20:51:44 +0100 Subject: [address-policy-wg] 2012-05 Proposal Accepted - Request for Clarification In-Reply-To: <20130213120441.GA5418@cilantro.c4inet.net> References: <20130213120441.GA5418@cilantro.c4inet.net> Message-ID: On Wed, Feb 13, 2013 at 1:04 PM, Sascha Luck wrote: > Hi, > > On Tue, Feb 12, 2013 at 03:55:30PM +0100, Emilio Madaio wrote: > >> The updated RIPE document is ripe-577 and is available at: >> >> https://www.ripe.net/ripe/docs/ripe-577 > > > ripe-577 contains, in S5.5 the sentence: > > "Re-allocated blocks will be signed to establish the current allocation > owner." > > What does this refer to? Does this mean these blocks will *mandatorily* > be signed with a RPKI certificate and, if yes, how does that square with > the NCC's stated policy that RPKI certs will always be voluntary? I really hope that's a type or forgotten connection somehow. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From lists-ripe at c4inet.net Wed Feb 13 21:07:22 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 13 Feb 2013 20:07:22 +0000 Subject: [address-policy-wg] 2012-05 Request for Clarification In-Reply-To: References: <20130213120441.GA5418@cilantro.c4inet.net> Message-ID: <20130213200722.GA6735@cilantro.c4inet.net> On Wed, Feb 13, 2013 at 08:51:44PM +0100, Roger J?rgensen wrote: >I really hope that's a type or forgotten connection somehow. That's quite possible, it came in in 2007 and pre-dates the rpki roll-out... cheers, Sascha From emadaio at ripe.net Mon Feb 18 15:08:18 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 18 Feb 2013 15:08:18 +0100 Subject: [address-policy-wg] 2012-06 Proposal Accepted (Revert "Run Out Fairly") Message-ID: Dear Colleagues Consensus has been reached, and the proposal for a change to RIPE Document ripe-577, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-06 The updated RIPE document is ripe-582 and is available at: https://www.ripe.net/ripe/docs/ripe-582 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From rogerj at gmail.com Tue Feb 19 08:46:37 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Tue, 19 Feb 2013 08:46:37 +0100 Subject: [address-policy-wg] Information/log over all temporarily/experimental assignments? Message-ID: Hi, Are there any place online where I can see how many, how long, and for what purpose assignments have been done under the temporary assignments policy? -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From ingrid at ripe.net Tue Feb 19 15:41:57 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 19 Feb 2013 15:41:57 +0100 Subject: [address-policy-wg] Information/log over all temporarily/experimental assignments? In-Reply-To: References: Message-ID: <51238F35.1060103@ripe.net> Dear Roger, The RIPE NCC does not publish temporary assignments in a separate list. However, most of the information you mention can be found. We do not publish the purpose of the assignment. Temporary assignments for IPv4 and 16-bit ASN are made from ranges specially reserved for this purpose: IPv4: 151.216.0.0/13 16-bit ASN: AS58352-AS58367 No range has been reserved for IPv6 or 32-bit ASN. A temporary assignment will also appear in the extended delegated statistics: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest These statistics are updated daily. Additionally, in the RIPE Database object, we add the following "remarks" line: remarks: Temporary assignment =========================================== Duration of assignment: 3 weeks =========================================== Start date: 07/11/2011 End date: 27/11/2011 ========================================== I hope this answers your question. Best regards, Ingrid Wijte RIPE NCC On 2/19/13 8:46 AM, Roger J?rgensen wrote: > Hi, > > Are there any place online where I can see how many, how long, and for > what purpose assignments have been done under the temporary > assignments policy? > > > From jan at go6.si Tue Feb 19 15:52:04 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 19 Feb 2013 15:52:04 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: <51239194.7060707@go6.si> On 2/11/13 2:54 PM, Emilio Madaio wrote: > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. Emilio, thank you for your help and assistance :) Dear AP Working Group, The 2012-10 proposal now moved to Review phase, so I would like to encourage you to read the draft again, as now it also contains the "Impact analysis" (that actually says "no impact" :) ) The proposers would like to thank you for *overwhelming* support in Discussion phase and would like to invite to express the support (or not-support) again - because of the procedural reasons. As per the PDP, a silent Review Phase does not mean consensus or support from the community. So if things remain silent, the APWG co-chairs may end up having trouble deciding how to move things forward. Thank you very much, Jan Zorz (on behalf of the proposers - Mark, Jordi and Jan) From ebais at a2b-internet.com Tue Feb 19 16:13:39 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 19 Feb 2013 16:13:39 +0100 Subject: [address-policy-wg] [policy-announce] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: <00d301ce0eb3$b2698e00$173caa00$@a2b-internet.com> Hi, > You can find the full proposal and the impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2012-10 > and the draft document at: > https://www.ripe.net/ripe/policies/proposals/2012-10/draft I support this policy. Regards, Erik Bais From Ragnar.Anfinsen at altibox.no Wed Feb 20 09:06:15 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Wed, 20 Feb 2013 08:06:15 +0000 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: Still support this proposal... MVH/Regards Ragnar > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Emilio Madaio > Sent: 11. februar 2013 14:54 > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2012-10 New Draft Document and Impact > Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR > basis) > > > Dear Colleagues, > > The draft document for the proposal described in 2012-10 has been > published. The impact analysis that was conducted for this proposal > has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-10 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From daryl.tanner at blueyonder.co.uk Wed Feb 20 16:53:44 2013 From: daryl.tanner at blueyonder.co.uk (Daryl Tanner) Date: Wed, 20 Feb 2013 15:53:44 +0000 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: I support this proposal Regards Daryl On 20 February 2013 08:06, Anfinsen, Ragnar wrote: > Still support this proposal... > > MVH/Regards > Ragnar > > > -----Original Message----- > > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > > bounces at ripe.net] On Behalf Of Emilio Madaio > > Sent: 11. februar 2013 14:54 > > To: policy-announce at ripe.net > > Cc: address-policy-wg at ripe.net > > Subject: [address-policy-wg] 2012-10 New Draft Document and Impact > > Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs > per-LIR > > basis) > > > > > > Dear Colleagues, > > > > The draft document for the proposal described in 2012-10 has been > > published. The impact analysis that was conducted for this proposal > > has also been published > > > > > > You can find the full proposal and the impact analysis at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-10 > > > > and the draft document at: > > > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > > > We encourage you to read the draft document text and send any comments > > to address-policy-wg at ripe.net before 11 March 2013. > > > > Regards > > > > Emilio Madaio > > Policy Development Officer > > RIPE NCC > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Feb 20 20:03:56 2013 From: gert at space.net (Gert Doering) Date: Wed, 20 Feb 2013 20:03:56 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: References: Message-ID: <20130220190356.GA22334@Space.Net> Dear AP WG, in the discussion phase, strong support was expressed for this proposal (and I'm happy to see such strong participation, as it makes Sander's and my life as chairs much easier). Unfortunately, participation in the current phase (review) has been a bit sparse so far - one voice in support, nothing else. We need a few more voices to comfortably decide "the community supports this proposal". The review phase ends on February 25, so please voice your opinion before that (otherwise we'll have to extend it...) thanks, Gert Doering, APWG Chair On Mon, Jan 28, 2013 at 02:11:23PM +0100, Emilio Madaio wrote: > > > Dear Colleagues, > > The draft document for the proposal described in 2012-09, > "Modification of The Time Limits For Temporary Internet Assignments", > has been published. The impact analysis that was conducted for this > proposal has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-09 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-09/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 25 February 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tore at fud.no Wed Feb 20 23:46:12 2013 From: tore at fud.no (Tore Anderson) Date: Wed, 20 Feb 2013 23:46:12 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <51255234.50308@fud.no> * Gert Doering > in the discussion phase, strong support was expressed for this > proposal (and I'm happy to see such strong participation, as it makes > Sander's and my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a > few more voices to comfortably decide "the community supports this > proposal". I wasn't aware that I had to repeat my statement of support for it to still count, but in any case - consider it done. -- Tore Anderson From nick at inex.ie Wed Feb 20 23:50:41 2013 From: nick at inex.ie (Nick Hilliard) Date: Wed, 20 Feb 2013 22:50:41 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51255234.50308@fud.no> References: <20130220190356.GA22334@Space.Net> <51255234.50308@fud.no> Message-ID: <51255341.80402@inex.ie> On 20/02/2013 22:46, Tore Anderson wrote: > I wasn't aware that I had to repeat my statement of support for it to > still count, but in any case - consider it done. It's an oddity of the PDP. I'm not sure if it serves a useful purpose because at the times when there are piles of proposals flying around (e.g. now), people end up getting jaded by the requirement for constant acks and me-toos. Nick From paul at meanie.nl Wed Feb 20 23:58:56 2013 From: paul at meanie.nl (Paul Hoogsteder) Date: Wed, 20 Feb 2013 23:58:56 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: Ah, yes. I do support this proposal. Even in the review phase ;-) Best regards, Paul Hoogsteder - who won't be able to attend RIPE Dublin :-( > Dear AP WG, > > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a few > more voices to comfortably decide "the community supports this proposal". > > The review phase ends on February 25, so please voice your opinion before > that (otherwise we'll have to extend it...) > > thanks, > > Gert Doering, > APWG Chair > > > On Mon, Jan 28, 2013 at 02:11:23PM +0100, Emilio Madaio wrote: >> >> >> Dear Colleagues, >> >> The draft document for the proposal described in 2012-09, >> "Modification of The Time Limits For Temporary Internet Assignments", >> has been published. The impact analysis that was conducted for this >> proposal has also been published >> >> >> You can find the full proposal and the impact analysis at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09/draft >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 25 February 2013. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > From Ragnar.Anfinsen at altibox.no Thu Feb 21 02:26:15 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Thu, 21 Feb 2013 01:26:15 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> Message-ID: I support this? :) /Ragnar On 20.02.13 20:03, "Gert Doering" wrote: >Dear AP WG, > >in the discussion phase, strong support was expressed for this proposal >(and I'm happy to see such strong participation, as it makes Sander's and >my life as chairs much easier). > >Unfortunately, participation in the current phase (review) has been a >bit sparse so far - one voice in support, nothing else. We need a few >more voices to comfortably decide "the community supports this proposal". > >The review phase ends on February 25, so please voice your opinion before >that (otherwise we'll have to extend it...) > >thanks, > >Gert Doering, > APWG Chair > > >On Mon, Jan 28, 2013 at 02:11:23PM +0100, Emilio Madaio wrote: >> >> >> Dear Colleagues, >> >> The draft document for the proposal described in 2012-09, >> "Modification of The Time Limits For Temporary Internet Assignments", >> has been published. The impact analysis that was conducted for this >> proposal has also been published >> >> >> You can find the full proposal and the impact analysis at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09/draft >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 25 February 2013. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> > > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > From Remco.vanMook at eu.equinix.com Thu Feb 21 08:47:29 2013 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 21 Feb 2013 07:47:29 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51255341.80402@inex.ie> Message-ID: On 2/20/13 23:50 , "Nick Hilliard" wrote: > >It's an oddity of the PDP. I'm not sure if it serves a useful purpose >because at the times when there are piles of proposals flying around (e.g. >now), people end up getting jaded by the requirement for constant acks and >me-toos. > +1, and yes, I again support this proposal. Remco van Mook Director of Interconnection, EMEA EQUINIX | 80 Cheapside, London, EC2V 6EE, United Kingdom E remco at equinix.com | T +31-6-11356365 HOW ARE WE DOING? Please click here to Tell Equinix - We're Listening Equinix.co.uk | Twitter | LinkedIn | Facebook | YouTube This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From ebais at a2b-internet.com Thu Feb 21 09:16:10 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 21 Feb 2013 09:16:10 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <007801ce100b$b506ced0$1f146c70$@a2b-internet.com> I support this proposal. Erik Bais From gert at space.net Thu Feb 21 09:50:47 2013 From: gert at space.net (Gert Doering) Date: Thu, 21 Feb 2013 09:50:47 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51255341.80402@inex.ie> References: <20130220190356.GA22334@Space.Net> <51255234.50308@fud.no> <51255341.80402@inex.ie> Message-ID: <20130221085047.GE51699@Space.Net> Hi, On Wed, Feb 20, 2013 at 10:50:41PM +0000, Nick Hilliard wrote: > On 20/02/2013 22:46, Tore Anderson wrote: > > I wasn't aware that I had to repeat my statement of support for it to > > still count, but in any case - consider it done. > > It's an oddity of the PDP. I'm not sure if it serves a useful purpose > because at the times when there are piles of proposals flying around (e.g. > now), people end up getting jaded by the requirement for constant acks and > me-toos. Yeah, the PDP is a bit heavy on "make sure that there is enough backing of the community, so nobody sneaks through anything while people are not looking". The need for extra input in the review phase is due to the fact that the proposal text might change between discussion and review phase, and also due to the impact analysis, which might change someone's opinion. Now, for 2012-09 and 2012-10, these are somewhat unusual - overwhelming support in discussion phase, no textual changes going to review phase, and an impact analysis that basically says "no impact" - so I can see that it feels a bit silly to have to re-state support again. But thanks anyway :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From ripencc-management at ripe.net Thu Feb 21 10:23:43 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Thu, 21 Feb 2013 10:23:43 +0100 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations Message-ID: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> [Apologies for duplicate emails] Dear colleagues, Based on recent discussions on the RIPE Address Policy WG mailing list, the RIPE NCC is now seeking policy related action from the RIPE community with regards to clear guidelines on how it should proceed with certifying transferred IPv4 allocations. It has recently come to our notice, via two of the policy authors, that the original intention (in 2007) of the sentence "Re-allocated blocks will be signed to establish the current allocation owner" was that the transferred block *must* be signed *after* the transfer in order to completely establish holdership. This sentence can be found under section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" here: http://www.ripe.net/ripe/docs/ripe-582#Transfers-of-Allocations Because the RIPE community provided guidance saying that certification should be an opt-in system, the RIPE NCC built an RPKI Certification system based on this opt-in notion, therefore it is not currently possible for the RIPE NCC to issue certificates without the resource holder initiating the process. Therefore, the RIPE NCC's interpretation and implementation of this specific sentence has been: Registration Services verifies and reflects the change in holdership of the re-allocated blocks by updating the database objects and internal records following the transfer. Any certificates that had been attached to these number resources before the transfer automatically become invalid/revoked due to the holdership change. The transfer recipient can then request a new certificate for the address space and the RIPE NCC will proceed to sign these resources to establish the current allocation holder. Therefore, the RIPE NCC does not make certification of any resources mandatory. As the sentence in section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is open to interpretation, the RIPE NCC is seeking representative(s) from the RIPE community to submit an update to ripe-582 that will replace this sentence with more accurate and appropriate wording or perhaps remove it completely. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From bosi at adm.dtu.dk Thu Feb 21 10:35:29 2013 From: bosi at adm.dtu.dk (=?iso-8859-1?Q?Bo_Sixten_St=E5hle?=) Date: Thu, 21 Feb 2013 09:35:29 +0000 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> Message-ID: +1 appropriate wording /Bo -------------- next part -------------- An HTML attachment was scrubbed... URL: From slz at baycix.de Thu Feb 21 11:10:43 2013 From: slz at baycix.de (Sascha Lenz) Date: Thu, 21 Feb 2013 11:10:43 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: *sigh* - support - (Outlook-style full-quoting intentionally to annoy the chairs) -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect Am 20.02.2013 um 20:03 schrieb Gert Doering : > Dear AP WG, > > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a few > more voices to comfortably decide "the community supports this proposal". > > The review phase ends on February 25, so please voice your opinion before > that (otherwise we'll have to extend it...) > > thanks, > > Gert Doering, > APWG Chair > > > On Mon, Jan 28, 2013 at 02:11:23PM +0100, Emilio Madaio wrote: >> >> >> Dear Colleagues, >> >> The draft document for the proposal described in 2012-09, >> "Modification of The Time Limits For Temporary Internet Assignments", >> has been published. The impact analysis that was conducted for this >> proposal has also been published >> >> >> You can find the full proposal and the impact analysis at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-09/draft >> >> We encourage you to read the draft document text and send any comments >> to address-policy-wg at ripe.net before 25 February 2013. >> >> Regards >> >> Emilio Madaio >> Policy Development Officer >> RIPE NCC >> >> > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > From hamed at skydsl.ir Thu Feb 21 11:18:32 2013 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Thu, 21 Feb 2013 13:48:32 +0330 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: References: <20130220190356.GA22334@Space.Net> Message-ID: +1,Support -- ----------------------------------------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Neukirch at xing.com Thu Feb 21 11:27:59 2013 From: Christoph.Neukirch at xing.com (Christoph Neukirch) Date: Thu, 21 Feb 2013 10:27:59 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> Message-ID: Am 20.02.13 20:03 schrieb "Gert Doering" unter : >Dear AP WG, > >in the discussion phase, strong support was expressed for this proposal >(and I'm happy to see such strong participation, as it makes Sander's and >my life as chairs much easier). > >Unfortunately, participation in the current phase (review) has been a >bit sparse so far - one voice in support, nothing else. We need a few >more voices to comfortably decide "the community supports this proposal". +1 support From dcunningham at airspeed.ie Thu Feb 21 11:52:45 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Thu, 21 Feb 2013 10:52:45 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: References: <20130220190356.GA22334@Space.Net> Message-ID: Gert Doering said: > We need a few more voices to comfortably decide that > "the community supports this proposal". +1 support D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie | +353 1 428 7531 From nigel at titley.com Thu Feb 21 12:11:07 2013 From: nigel at titley.com (Nigel Titley) Date: Thu, 21 Feb 2013 11:11:07 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <512600CB.9050800@titley.com> On 20/02/2013 19:03, Gert Doering wrote: > Dear AP WG, > > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a few > more voices to comfortably decide "the community supports this proposal". > > The review phase ends on February 25, so please voice your opinion before > that (otherwise we'll have to extend it...) > Yes, please, +1 Nigel From rogerj at gmail.com Thu Feb 21 12:21:04 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 21 Feb 2013 12:21:04 +0100 Subject: [address-policy-wg] Information/log over all temporarily/experimental assignments? In-Reply-To: <51238F35.1060103@ripe.net> References: <51238F35.1060103@ripe.net> Message-ID: On Tue, Feb 19, 2013 at 3:41 PM, Ingrid Wijte wrote: > Dear Roger, > > The RIPE NCC does not publish temporary assignments in a separate list. > However, most of the information you mention can be found. We do not publish > the purpose of the assignment. > > Temporary assignments for IPv4 and 16-bit ASN are made from ranges > specially reserved for this purpose: > IPv4: 151.216.0.0/13 > 16-bit ASN: AS58352-AS58367 > > No range has been reserved for IPv6 or 32-bit ASN. > > A temporary assignment will also appear in the extended delegated > statistics: > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest > > These statistics are updated daily. > > Additionally, in the RIPE Database object, we add the following "remarks" > line: > > remarks: Temporary assignment > =========================================== > Duration of assignment: 3 weeks > =========================================== > Start date: 07/11/2011 > End date: 27/11/2011 > ========================================== > > > I hope this answers your question. thanks, that was a complete answer:-) I would wish there was a log, but that rise more issues again so at the current time I'm happy as it is. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From jan at go6.si Thu Feb 21 12:28:19 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 21 Feb 2013 12:28:19 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51255234.50308@fud.no> References: <20130220190356.GA22334@Space.Net> <51255234.50308@fud.no> Message-ID: <512604D3.8060001@go6.si> On 2/20/13 11:46 PM, Tore Anderson wrote: >> Unfortunately, participation in the current phase (review) has been a >> bit sparse so far - one voice in support, nothing else. We need a >> few more voices to comfortably decide "the community supports this >> proposal". > > I wasn't aware that I had to repeat my statement of support for it to > still count, but in any case - consider it done. > The same as for 2012-10... need to re-state the support in Review phase, even though many of folx stated it in Discussion phase. This procedure is not the best one possible, people usually are not very happy doing the same thing twice. Cheers, Jan From jan at go6.si Thu Feb 21 12:29:09 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 21 Feb 2013 12:29:09 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51255341.80402@inex.ie> References: <20130220190356.GA22334@Space.Net> <51255234.50308@fud.no> <51255341.80402@inex.ie> Message-ID: <51260505.6050405@go6.si> On 2/20/13 11:50 PM, Nick Hilliard wrote: > On 20/02/2013 22:46, Tore Anderson wrote: >> I wasn't aware that I had to repeat my statement of support for it to >> still count, but in any case - consider it done. > > It's an oddity of the PDP. I'm not sure if it serves a useful purpose > because at the times when there are piles of proposals flying around (e.g. > now), people end up getting jaded by the requirement for constant acks and > me-toos. Agree... is this painful enough that we need to change it? Cheers, Jan From gert at space.net Thu Feb 21 12:31:15 2013 From: gert at space.net (Gert Doering) Date: Thu, 21 Feb 2013 12:31:15 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <51260505.6050405@go6.si> References: <20130220190356.GA22334@Space.Net> <51255234.50308@fud.no> <51255341.80402@inex.ie> <51260505.6050405@go6.si> Message-ID: <20130221113115.GG51699@Space.Net> Hi, On Thu, Feb 21, 2013 at 12:29:09PM +0100, Jan Zorz @ go6.si wrote: > On 2/20/13 11:50 PM, Nick Hilliard wrote: > > On 20/02/2013 22:46, Tore Anderson wrote: > >> I wasn't aware that I had to repeat my statement of support for it to > >> still count, but in any case - consider it done. > > > > It's an oddity of the PDP. I'm not sure if it serves a useful purpose > > because at the times when there are piles of proposals flying around (e.g. > > now), people end up getting jaded by the requirement for constant acks and > > me-toos. > > Agree... is this painful enough that we need to change it? See my other e-mail on this topic - it serves a purpose, as the proposal might have changed significantly when entering review phase, or the impact analysis might have turned up some "unintended consequences". Plus, usually there is not so strong "yes, make it happen, now!" support in the discussion phase, but more of an actual *discussion* :-) These two proposals (2012-09 and 2012-10) are untypical. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From rogerj at gmail.com Thu Feb 21 12:35:14 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 21 Feb 2013 12:35:14 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: On Wed, Feb 20, 2013 at 8:03 PM, Gert Doering wrote: > Dear AP WG, > > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a few > more voices to comfortably decide "the community supports this proposal". > > The review phase ends on February 25, so please voice your opinion before > that (otherwise we'll have to extend it...) supported. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From dogwallah at gmail.com Thu Feb 21 13:46:37 2013 From: dogwallah at gmail.com (McTim) Date: Thu, 21 Feb 2013 07:46:37 -0500 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> Message-ID: On Thu, Feb 21, 2013 at 4:23 AM, Andrew de la Haye < ripencc-management at ripe.net> wrote: > [Apologies for duplicate emails] > > Dear colleagues, > > Based on recent discussions on the RIPE Address Policy WG mailing list, > the RIPE NCC is now seeking policy related action from the RIPE > community with regards to clear guidelines on how it should proceed with > certifying transferred IPv4 allocations. > > It has recently come to our notice, via two of the policy authors, that > the original intention (in 2007) of the sentence "Re-allocated blocks > will be signed to establish the current allocation owner" was that the > transferred block *must* be signed *after* the transfer in order to > completely establish holdership. > > This sentence can be found under section 5.5 of "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region" here: > http://www.ripe.net/ripe/docs/ripe-582#Transfers-of-Allocations > > Because the RIPE community provided guidance saying that certification > should be an opt-in system, the RIPE NCC built an RPKI Certification > system based on this opt-in notion, therefore it is not currently > possible for the RIPE NCC to issue certificates without the resource > holder initiating the process. > > Therefore, the RIPE NCC's interpretation and implementation of this > specific sentence has been: > > Registration Services verifies and reflects the change in holdership of > the re-allocated blocks by updating the database objects and internal > records following the transfer. Any certificates that had been attached > to these number resources before the transfer automatically become > invalid/revoked due to the holdership change. The transfer recipient can > then request a new certificate for the address space and the RIPE NCC > will proceed to sign these resources to establish the current allocation > holder. > > Therefore, the RIPE NCC does not make certification of any resources > mandatory. > > As the sentence in section 5.5 of "IPv4 Address Allocation and > Assignment Policies for the RIPE NCC Service Region" is open to > interpretation, the RIPE NCC is seeking representative(s) from the RIPE > community to submit an update to ripe-582 that will replace this > sentence with more accurate and appropriate wording or perhaps remove it > completely. > How about replacing; "Re-allocated blocks will be signed to establish the current allocation owner." with: "Re-allocated blocks will be signed to establish the current allocation holder if the receiving party chooses." ?? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-list+ml at x-net.be Thu Feb 21 14:37:55 2013 From: ripe-list+ml at x-net.be (Gerry Demaret) Date: Thu, 21 Feb 2013 14:37:55 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <51262333.6050701@x-net.be> On 02/20/2013 08:03 PM, Gert Doering wrote: > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). > > Unfortunately, participation in the current phase (review) has been a > bit sparse so far - one voice in support, nothing else. We need a few > more voices to comfortably decide "the community supports this proposal". > > The review phase ends on February 25, so please voice your opinion before > that (otherwise we'll have to extend it...) I support policy 2012-09. -- Gerry From tore at fud.no Thu Feb 21 14:52:12 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 21 Feb 2013 14:52:12 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: <5126268C.1040303@fud.no> * Emilio Madaio > https://www.ripe.net/ripe/policies/proposals/2012-10 Support. -- Tore Anderson From dcunningham at airspeed.ie Thu Feb 21 15:21:33 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Thu, 21 Feb 2013 14:21:33 +0000 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> Message-ID: > "Re-allocated blocks will be signed to establish the current > allocation holder if the receiving party chooses." Replace "will" with "may"? You could also add "so" before the word "chooses". D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie | +353 1 428 7531 From lists-ripe at c4inet.net Thu Feb 21 16:01:29 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 21 Feb 2013 15:01:29 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <20130221150129.GA47797@cilantro.c4inet.net> On Wed, Feb 20, 2013 at 08:03:56PM +0100, Gert Doering wrote: >The review phase ends on February 25, so please voice your opinion >before that (otherwise we'll have to extend it...) Supported it in discussion, still supporting it in review. :) rgds, Sascha Luck From farmer at umn.edu Thu Feb 21 15:52:18 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 21 Feb 2013 08:52:18 -0600 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> Message-ID: <512634A2.6000606@umn.edu> On 2/21/13 08:21 , Donal Cunningham wrote: >> "Re-allocated blocks will be signed to establish the current >> allocation holder if the receiving party chooses." > > Replace "will" with "may"? You could also add "so" > before the word "chooses". May I also suggest, s/signed/certified, and add to the end ", and any previous related certificates will be revoked." Revocation of previous related certificates is required if their are any, and not optional, new certificates for the new holder are optional. Put it all together and you get; "Re-allocated blocks may be certified to establish the current allocation holder if the receiving party so chooses, and any previous related certificates will be revoked." -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From gert at space.net Thu Feb 21 16:12:07 2013 From: gert at space.net (Gert Doering) Date: Thu, 21 Feb 2013 16:12:07 +0100 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <512634A2.6000606@umn.edu> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> Message-ID: <20130221151207.GI51699@Space.Net> Hi, On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote: > "Re-allocated blocks may be certified to establish the current > allocation holder if the receiving party so chooses, and any previous > related certificates will be revoked." Works for me :-) - but now we need someone to volunteer to formally drive this through the policy development process (PDP)... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nick at inex.ie Thu Feb 21 17:15:19 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Feb 2013 16:15:19 +0000 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <20130221151207.GI51699@Space.Net> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> Message-ID: <51264817.3050101@inex.ie> On 21/02/2013 15:12, Gert Doering wrote: > On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote: >> "Re-allocated blocks may be certified to establish the current >> allocation holder if the receiving party so chooses, and any previous >> related certificates will be revoked." > > Works for me :-) - but now we need someone to volunteer to formally drive > this through the policy development process (PDP)... This is a bad idea for two reasons: 1. I don't think it's a good idea to have non-atomic policy. I.e. if there's RPKI policy statements here where they don't really need to be, then this creates unnecessary confusion. If there is no statement about RPKI policy in here, then I expect the default action by the RIPE NCC will be to treat these allocations as regular allocation 2. by explicitly mentioning RPKI and certification, the proposal will be to create a RIPE policy which will permit certification for reallocated blocks only. This will do two things: 2.1. create a RIPE policy discrepancy between how RPKI is handled for reallocated resources and resources which are still assigned to their original holders. 2.2. re-open the discussion about resource certification at half-cock, which will lead to a re-run of the same arguments put forward for 2008-08. The intention of the policy change here is to fix a policy bug, and it would be a shame to have it ending up as an unnecessary re-hash of 2008-08. The easiest and simplest thing would be to drop the sentence completely, at which point the de-facto RIPE NCC procedures concerning certification will apply. If this seems like a sensible and pragmatic approach to others, I can oblige from the policy proposal point of view. Or someone else can, if they want. Nick From lists-ripe at c4inet.net Thu Feb 21 17:27:58 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 21 Feb 2013 16:27:58 +0000 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51264817.3050101@inex.ie> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <51264817.3050101@inex.ie> Message-ID: <20130221162758.GA48258@cilantro.c4inet.net> On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote: >2.2. re-open the discussion about resource certification at half-cock, >which will lead to a re-run of the same arguments put forward for 2008-08. >The intention of the policy change here is to fix a policy bug, and it >would be a shame to have it ending up as an unnecessary re-hash of 2008-08. Damn. I never looked at it from that angle. Nick is right, this creates RPKI policy by the back-door. >The easiest and simplest thing would be to drop the sentence completely, at >which point the de-facto RIPE NCC procedures concerning certification will >apply. If this seems like a sensible and pragmatic approach to others, I >can oblige from the policy proposal point of view. Or someone else can, if >they want. In light of the above, this is eminently the most sensible solution. cheers, Sascha Luck From info at leadertelecom.ru Thu Feb 21 17:30:14 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Thu, 21 Feb 2013 20:30:14 +0400 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51264817.3050101@inex.ie> References: <51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> Message-ID: <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> Why not stop?RPKI?certification? It looks unnecessary any brings for community too many difficulties in support and additional costs.? In Russia can be used only GOST encryption and special certified equipment. So if operator will use RPKI-cerfification - then he will break Russian law.? -- Alexey Ivanov LeaderTelecom? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Thu Feb 21 17:30:47 2013 From: dogwallah at gmail.com (McTim) Date: Thu, 21 Feb 2013 11:30:47 -0500 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <20130221162758.GA48258@cilantro.c4inet.net> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <51264817.3050101@inex.ie> <20130221162758.GA48258@cilantro.c4inet.net> Message-ID: On Thu, Feb 21, 2013 at 11:27 AM, Sascha Luck wrote: > On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote: > > 2.2. re-open the discussion about resource certification at half-cock, >> which will lead to a re-run of the same arguments put forward for 2008-08. >> The intention of the policy change here is to fix a policy bug, and it >> would be a shame to have it ending up as an unnecessary re-hash of >> 2008-08. >> > > Damn. I never looked at it from that angle. Nick is right, this creates > RPKI policy by the back-door. I'm not so sure it does, the word "may" doesn't obligate the NCC to do anything. > > > The easiest and simplest thing would be to drop the sentence completely, >> at >> which point the de-facto RIPE NCC procedures concerning certification will >> apply. If this seems like a sensible and pragmatic approach to others, I >> can oblige from the policy proposal point of view. Or someone else can, >> if >> they want. >> > > In light of the above, this is eminently the most sensible solution. > Probably. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Feb 21 17:34:19 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Feb 2013 16:34:19 +0000 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> References: <51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> Message-ID: <51264C8B.3090502@inex.ie> On 21/02/2013 16:30, LeaderTelecom Ltd. wrote: > Why not stop RPKI certification? It looks unnecessary any brings for > community too many difficulties in support and additional costs. Alexey, this is a different argument for another time. Right now, we need to fix a policy bug which is causing the RIPE NCC difficulties. Let's fix that and deal with the RPKI / certification issue separately. Nick From farmer at umn.edu Thu Feb 21 17:59:09 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 21 Feb 2013 10:59:09 -0600 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <51264817.3050101@inex.ie> <20130221162758.GA48258@cilantro.c4inet.net> Message-ID: <5126525D.2060008@umn.edu> On 2/21/13 10:30 , McTim wrote: > On Thu, Feb 21, 2013 at 11:27 AM, Sascha Luck > wrote: > > On Thu, Feb 21, 2013 at 04:15:19PM +0000, Nick Hilliard wrote: > > 2.2. re-open the discussion about resource certification at > half-cock, > which will lead to a re-run of the same arguments put forward > for 2008-08. > The intention of the policy change here is to fix a policy bug, > and it > would be a shame to have it ending up as an unnecessary re-hash > of 2008-08. > > Damn. I never looked at it from that angle. Nick is right, this creates > RPKI policy by the back-door. > > I'm not so sure it does, the word "may" doesn't obligate the NCC to do > anything. While I tend to agree that it doesn't actually create RPKI policy, the fact that it would be mentioning certificates or signing at all does create an impression that it is creating RPKI policy. > The easiest and simplest thing would be to drop the sentence > completely, at > which point the de-facto RIPE NCC procedures concerning > certification will > apply. If this seems like a sensible and pragmatic approach to > others, I > can oblige from the policy proposal point of view. Or someone > else can, if > they want. > > In light of the above, this is eminently the most sensible solution. > > Probably. Given the lack of actual RPKI policy, it seems sensible to not create any confusion or give the impression that there is backdoor RPKI policy being created and just remove the sentence completely. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From Woeber at CC.UniVie.ac.at Thu Feb 21 17:58:40 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 21 Feb 2013 17:58:40 +0100 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51264817.3050101@inex.ie> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <51264817.3050101@inex.ie> Message-ID: <51265240.5020800@CC.UniVie.ac.at> Nick Hilliard wrote: > On 21/02/2013 15:12, Gert Doering wrote: > >>On Thu, Feb 21, 2013 at 08:52:18AM -0600, David Farmer wrote: >> >>>"Re-allocated blocks may be certified to establish the current >>>allocation holder if the receiving party so chooses, and any previous >>>related certificates will be revoked." >> >>Works for me :-) - but now we need someone to volunteer to formally drive >>this through the policy development process (PDP)... > > > This is a bad idea for two reasons: [...] > The easiest and simplest thing would be to drop the sentence completely, at > which point the de-facto RIPE NCC procedures concerning certification will > apply. full support. Just as an observation, imho we are suffering from a mixup of terminology and a lack of experience with all the "funny" details of establishing a (sort of) hierarchical CA and RA environment. The RPKI is meant to create, distribute and manage certificates for the routing plane, not as a digital signature of ownership, true? The authoritative source of information about holdership is the up-to-date Numbers Registry. > If this seems like a sensible and pragmatic approach to others, I > can oblige from the policy proposal point of view. Or someone else can, if > they want. > > Nick Wilfried. From Woeber at CC.UniVie.ac.at Thu Feb 21 18:45:19 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 21 Feb 2013 18:45:19 +0100 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51265240.5020800@CC.UniVie.ac.at> References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <51264817.3050101@inex.ie> <51265240.5020800@CC.UniVie.ac.at> Message-ID: <51265D2F.1010108@CC.UniVie.ac.at> Wilfried Woeber wrote: > Nick Hilliard wrote: [...] > The RPKI is meant to create, distribute and manage certificates for the > routing plane, not as a digital signature of ownership, true? Correction to self: ripe-549 1.4.1 says: "The certificates issued under this hierarchy are for authorisation in support of validation of claims of current holdings of address space and/or AS Numbers. With regard to routing security, an initial goal of this PKI is to allow the holder of a set of address blocks to be able to declare, in a secure fashion, the AS Number of each entity that is authorised to originate a route to these addresses, including the context of ISP proxy aggregation. Additional uses of the PKI, consistent with the basic goal cited above, are also permitted under this policy." while 1.4.2 says: "Any uses other than those described in section 1. 4. 1 are prohibited." which seems to be somewhat contradictory or at least inconsistent. and 1.3.2 seems to indicate that only RIPE NCC Members are eligible. > The authoritative source of information about holdership is the up-to-date > Numbers Registry. > > >> If this seems like a sensible and pragmatic approach to others, I >>can oblige from the policy proposal point of view. Or someone else can, if >>they want. >> >>Nick > > > Wilfried. Wilfried From Remco.vanMook at eu.equinix.com Thu Feb 21 19:23:40 2013 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Thu, 21 Feb 2013 18:23:40 +0000 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51264817.3050101@inex.ie> Message-ID: On 2/21/13 17:15 , "Nick Hilliard" wrote: >The easiest and simplest thing would be to drop the sentence completely, >at >which point the de-facto RIPE NCC procedures concerning certification will >apply. If this seems like a sensible and pragmatic approach to others, I >can oblige from the policy proposal point of view. Or someone else can, >if >they want. +1. Support completely. Even willing to volunteer as token author for sake of the PDP if necessary. Remco This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From info at leadertelecom.ru Thu Feb 21 20:49:36 2013 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Thu, 21 Feb 2013 23:49:36 +0400 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <51264C8B.3090502@inex.ie> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> Message-ID: <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> Dear Nick, This is simplest way to fix :) No?RPKI - no problem with certification. -- Alexey Ivanov 21.02.2013 20:41 - Nick Hilliard ???????(?): On 21/02/2013 16:30, LeaderTelecom Ltd. wrote: > Why not stop RPKI certification? It looks unnecessary any brings for > community too many difficulties in support and additional costs. Alexey, this is a different argument for another time.??Right now, we need to fix a policy bug which is causing the RIPE NCC difficulties.??Let's fix that and deal with the RPKI / certification issue separately. Nick ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at bais.name Fri Feb 22 11:53:43 2013 From: erik at bais.name (Erik Bais) Date: Fri, 22 Feb 2013 10:53:43 +0000 Subject: [address-policy-wg] Was : RE: 2012-09 - now : PDP 'I Agree discussion' Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C204D66D7@e2010-mbx-c1n1.exchange2010.nl> Hi Jan, >> It's an oddity of the PDP. I'm not sure if it serves a useful purpose >> because at the times when there are piles of proposals flying around (e.g. >> now), people end up getting jaded by the requirement for constant acks >> and me-toos. >Agree... is this painful enough that we need to change it? Looking at how the process currently goes, I don't think that changing this would make everyone his/her live so much easier. Personally I think doing it the way that we currently do it, might look a bit redundant, but it does provide clear consensus during all phases of the PDP. Typically we seem to be pretty easy to get on top of policies again if it is needed .. (just look at the simple email from one of the chairs to restate support in the current phase / or state of the proposal. ) How would you propose to change it if it would be changed ? Erik Bais From niall.oreilly at ucd.ie Fri Feb 22 12:45:03 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Fri, 22 Feb 2013 11:45:03 +0000 Subject: [address-policy-wg] Was : RE: 2012-09 - now : PDP 'I Agree discussion' In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204D66D7@e2010-mbx-c1n1.exchange2010.nl> References: <862A73D42343AE49B2FC3C32FDDFE91C204D66D7@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <2DDFA657-41C4-4B99-A75F-86E02D950C76@ucd.ie> On 22 Feb 2013, at 10:53, Erik Bais wrote: > Looking at how the process currently goes, I don't think that changing this would make everyone his/her live so much easier. Personally I think doing it the way that we currently do it, might look a bit redundant, but it does provide clear consensus during all phases of the PDP. Absolutely. > Typically we seem to be pretty easy to get on top of policies again if it is needed .. (just look at the simple email from one of the chairs to restate support in the current phase / or state of the proposal. ) > > How would you propose to change it if it would be changed ? [D?j?-vu alert: I did send something like this to the WG Chairs list already] (Co-) Chair(s) of the WG where the policy is being developed could be allowed to take the initiative of declaring on the list that there were sufficient grounds (for example: overwhelming support in Discussion Phase and no impact) for considering earlier support as carrying over into the Review Phase, and that because of this silence would exceptionally be taken as consent. That would seem to give an opportunity to save effort and irritation. Would it still be safe and transparent enough? /Niall From jan at go6.si Sat Feb 23 00:41:12 2013 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 23 Feb 2013 00:41:12 +0100 Subject: [address-policy-wg] Was : RE: 2012-09 - now : PDP 'I Agree discussion' In-Reply-To: <2DDFA657-41C4-4B99-A75F-86E02D950C76@ucd.ie> References: <862A73D42343AE49B2FC3C32FDDFE91C204D66D7@e2010-mbx-c1n1.exchange2010.nl> <2DDFA657-41C4-4B99-A75F-86E02D950C76@ucd.ie> Message-ID: <51280218.5060403@go6.si> On 2/22/13 12:45 PM, Niall O'Reilly wrote: > (Co-) Chair(s) of the WG where the policy is being developed could be > allowed to take the initiative of declaring on the list that there were > sufficient grounds (for example: overwhelming support in Discussion Phase > and no impact) for considering earlier support as carrying over into the > Review Phase, and that because of this silence would exceptionally be > taken as consent. > > That would seem to give an opportunity to save effort and irritation. Niall, Eric, @WG... This seems like a good idea to me. Chairs are there to determine a consensus and something like this would be a great addition to the variety of ways in which they can actually do their job :) Cheers, Jan From richih.mailinglist at gmail.com Sat Feb 23 10:24:59 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 23 Feb 2013 10:24:59 +0100 Subject: [address-policy-wg] Was : RE: 2012-09 - now : PDP 'I Agree discussion' In-Reply-To: <2DDFA657-41C4-4B99-A75F-86E02D950C76@ucd.ie> References: <862A73D42343AE49B2FC3C32FDDFE91C204D66D7@e2010-mbx-c1n1.exchange2010.nl> <2DDFA657-41C4-4B99-A75F-86E02D950C76@ucd.ie> Message-ID: On Feb 22, 2013 2:09 PM, "Niall O'Reilly" wrote: > (Co-) Chair(s) of the WG where the policy is being developed could be > allowed to take the initiative of declaring on the list that there were > sufficient grounds (for example: overwhelming support in Discussion Phase > and no impact) for considering earlier support as carrying over into the > Review Phase, and that because of this silence would exceptionally be > taken as consent. I think the current system is designed to make sure such interpretation is not needed, reducing the chance for errors and misunderstandings. As Gert pointed out repeatedly, we are dealing with two outliers here anyway, significantly changing the process just for those seems unwise. Why not ask all chairs to state explicitly in all their announcements that new ayes and nays are needed for that specific phase? Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nigel at titley.com Sat Feb 23 23:53:00 2013 From: nigel at titley.com (Nigel Titley) Date: Sat, 23 Feb 2013 22:53:00 +0000 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> Message-ID: <5129484C.3020002@titley.com> On 21/02/13 19:49, LeaderTelecom Ltd. wrote: > Dear Nick, > > This is simplest way to fix :) > > No RPKI - no problem with certification. Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time. I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed. Nigel From mueller at syr.edu Sun Feb 24 00:40:44 2013 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 23 Feb 2013 23:40:44 +0000 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <5129484C.3020002@titley.com> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD2355419@SUEX10-mbx-10.ad.syr.edu> I agree. > -----Original Message----- > > I'd suggest (as the original author of this particular clause) that we > just remove it. Times have changed. > > Nigel Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org From ripe.address-policy-wg at ml.karotte.org Sun Feb 24 14:13:43 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Sun, 24 Feb 2013 14:13:43 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: <20130224131343.GB30344@danton.fire-world.de> * Emilio Madaio [2013-02-11 14:57]: > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-10 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. +1 -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From ripe.address-policy-wg at ml.karotte.org Sun Feb 24 14:17:26 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Sun, 24 Feb 2013 14:17:26 +0100 Subject: [address-policy-wg] Policy update request on certification of transferred IPv4 allocations In-Reply-To: References: <791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> Message-ID: <20130224131726.GC30344@danton.fire-world.de> * Donal Cunningham [2013-02-21 15:24]: > > "Re-allocated blocks will be signed to establish the current > > allocation holder if the receiving party chooses." > > Replace "will" with "may"? You could also add "so" > before the word "chooses". As this makes it completely optional I would suggest just removing the sentence. The receiver can always sign it if he chooses to do so. Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From ripe.address-policy-wg at ml.karotte.org Sun Feb 24 14:12:21 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Sun, 24 Feb 2013 14:12:21 +0100 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: <20130220190356.GA22334@Space.Net> Message-ID: <20130224131221.GA30344@danton.fire-world.de> * Gert Doering [2013-02-20 20:06]: > Dear AP WG, > > in the discussion phase, strong support was expressed for this proposal > (and I'm happy to see such strong participation, as it makes Sander's and > my life as chairs much easier). Make it so! Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From maildanrl at gmail.com Sun Feb 24 14:17:16 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Sun, 24 Feb 2013 14:17:16 +0100 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: <20130224131343.GB30344@danton.fire-world.de> References: <20130224131343.GB30344@danton.fire-world.de> Message-ID: Supporting. -- Dan Luedtke http://www.danrl.de From richih.mailinglist at gmail.com Sun Feb 24 17:20:02 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sun, 24 Feb 2013 17:20:02 +0100 Subject: [address-policy-wg] [policy-announce] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: Support. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mps31.ripe at gmail.com Sun Feb 24 20:02:48 2013 From: mps31.ripe at gmail.com (Mike Simkins) Date: Sun, 24 Feb 2013 19:02:48 +0000 Subject: [address-policy-wg] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: Support On 11 Feb 2013, at 13:54, Emilio Madaio wrote: > > Dear Colleagues, > > The draft document for the proposal described in 2012-10 has been > published. The impact analysis that was conducted for this proposal > has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-10 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > From sciacco at iperweb.com Mon Feb 25 10:17:23 2013 From: sciacco at iperweb.com (Salvatore Sciacco) Date: Mon, 25 Feb 2013 10:17:23 +0100 Subject: [address-policy-wg] [policy-announce] 2012-10 New Draft Document and Impact Analysis Published (Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis) In-Reply-To: References: Message-ID: Support Il giorno 11/feb/2013 14:54, "Emilio Madaio" ha scritto: > > Dear Colleagues, > > The draft document for the proposal described in 2012-10 has been > published. The impact analysis that was conducted for this proposal > has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-10 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-10/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 March 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at bais.name Mon Feb 25 11:51:05 2013 From: erik at bais.name (Erik Bais) Date: Mon, 25 Feb 2013 10:51:05 +0000 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <5129484C.3020002@titley.com> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> Hi, > Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time. > I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed. That means that it is up to the parties themselves to revoke their current certificate (if they have one already) and create a new one if needed. The only question is how long would it be before the transfer be completed in the RIPE system, to allow the new LIR to setup their new ROA. Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer. Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... ) Regards, Erik Bais From alexb at ripe.net Mon Feb 25 13:48:52 2013 From: alexb at ripe.net (Alex Band) Date: Mon, 25 Feb 2013 13:48:52 +0100 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> Message-ID: <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> On 25 Feb 2013, at 11:51, Erik Bais wrote: > Hi, > >> Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time. > >> I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed. > > That means that it is up to the parties themselves to revoke their current certificate (if they have one already) and create a new one if needed. There is no need for this. The content of the certificate is based on current Registry data. If resources are de-registered from an LIR, a new, updated certificate is automatically issued and any over-claiming ROAs will be invalidated. > The only question is how long would it be before the transfer be completed in the RIPE system, to allow the new LIR to setup their new ROA. As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below. > Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer. The BGP announcement of a prefix will *not* be invalid in this case (a common misconception). There are three validity states of BGP announcements in relation to ROAs to consider: - valid (ROA exists) - invalid (ROA exists for the prefix, but for a different ASN or max prefix length) - unknown (no ROA exists for the prefix) So while a transfer is ongoing, the associated BGP announcements will be "unknown" because no ROA exists (yet). If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that. > Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... ) As said, the process is fully automated so no action is required from the transferring LIR. The LIR who receives the resources is free to request a certificate and create ROAs, if they so choose. Cheers, Alex From ebais at a2b-internet.com Mon Feb 25 15:24:37 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 25 Feb 2013 15:24:37 +0100 Subject: [address-policy-wg] [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <20130225132938.GS27968@x28.adm.denic.de> References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> Peter makes some very good points here. If the End User doesn't know who their Sponsoring LIR is, there is nothing keeping them from transferring the resource to another LIR. You would be surprised how may LIR's are sponsoring PI space without any contract or charge to their customers of 8 years ago ... and those LIR's still keep paying the bill to RIPE. Last year I cleaned up an LIR of 25+ PI resources of former customers. If the LIR themselves is unaware of the situation or simply don't care and the customer never receives any invoice for resources. Who are we to decide to publish this information. The last argument, that it would make abuse easier ... /sigh. Being a sponsoring LIR has nothing to do with abuse management. Being an LIR has nothing to do with having a network or route packets. Being / running an LIR doesn't mean you have your own network .. nor does it say that you are an ISP .. or a hoster. You are running a resource registration office. Yes we register PI space for end-users, even if they are not consuming our network services. We charge end-users for that service, we provide RIPE with all the required paperwork and handle the PI request, but if someone is routing some "bad" packets on the IP's we registered for them in the past, why would it help abuse if someone knows who registered the PI space in the first place? It is not that we can put a null-route for the IP's or 'drop the BGP announcement' as they are not in our network. Perhaps the name 'Sponsoring LIR' is a bit tricky as it might give the impression it is for free. But registration of resources (PI space, AS numbers etc) is just like any other kind of registration services, it takes time to provide the service and we charge for the time. So, perhaps a bit longer story than what Peter said, but the result it the same. Not in favor for this policy. Regards, Erik Bais A2B Internet From ebais at a2b-internet.com Mon Feb 25 15:48:11 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 25 Feb 2013 15:48:11 +0100 Subject: [address-policy-wg] [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> Hi Daniel, > We see it quite often. And the answer is that the sponsorships is rather an entry in some hidden RIPE db than a contract. When an end user is asked "Do you have a sponsoring LIR for this resource and if so, who is it?", the answer is usuallu " > We have no idea". And the only way to be certain is to send an email to the RIPE hostmasters. If you don't know, check the LIR Portal to see the registered PI spaces you hold there. For the customer, there is no requirement (if they really don't know.. ) and not get an invoice from some LIR, so it is very easy to just transfer the resources to another LIR and that way you are both sure ... > Let's say you do have the documents in the first situation. How do you know they are still valid? Yes, we used to be sponsor for this resource but how do we know that in RIPE:s point of view, we still are? Again, check the LIR portal for the registered PI resources under your LIR account. If there are company changes for the registered resources, inform the RIPE NCC that that is the case, send them the old info and the new info and if needed you will be requested additional paperwork of information. Typically, it is a 10 minute fix for a contact or address change. That is what it means to be a LIR, too many people see being an LIR as a way to get resources for themselves. We have customers that we provide RIPE Administration services for, they are an LIR themselves, but stay away from the actual administration or registration part. If an End-Customer wants a more formal registration service instead of a 'sponsoring LIR, could you do me a favor' kind of service, you should transfer the resources of that customer to your LIR within a blink of an eye ... Don't you think ? Publishing the information who the registration LIR is, doesn't fix the fact that information might not be correct. Go through the process of a PI transfer as an actual LIR and then decide if this is still something that is required. Regards, Erik Bais From js at dacor.de Mon Feb 25 16:02:25 2013 From: js at dacor.de (Julian Seifert) Date: Mon, 25 Feb 2013 15:02:25 +0000 Subject: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <20130220190356.GA22334@Space.Net> References: , <20130220190356.GA22334@Space.Net> Message-ID: <71875FE4961EEE40BA4AACF7168091DE1CCAB4A5@exchange.suecdacor.local> (still ;)) supporting it (policy 2012-09) Mit freundlichen Gr??en, Julian Seifert ________________________________________ Von: address-policy-wg-bounces at ripe.net [address-policy-wg-bounces at ripe.net]" im Auftrag von "Gert Doering [gert at space.net] Gesendet: Mittwoch, 20. Februar 2013 20:03 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2012-09 New Draft Document and Impact Analysis Published (Modification of The Time Limits For Temporary Internet Assignments) Dear AP WG, in the discussion phase, strong support was expressed for this proposal (and I'm happy to see such strong participation, as it makes Sander's and my life as chairs much easier). Unfortunately, participation in the current phase (review) has been a bit sparse so far - one voice in support, nothing else. We need a few more voices to comfortably decide "the community supports this proposal". The review phase ends on February 25, so please voice your opinion before that (otherwise we'll have to extend it...) thanks, Gert Doering, APWG Chair On Mon, Jan 28, 2013 at 02:11:23PM +0100, Emilio Madaio wrote: > > > Dear Colleagues, > > The draft document for the proposal described in 2012-09, > "Modification of The Time Limits For Temporary Internet Assignments", > has been published. The impact analysis that was conducted for this > proposal has also been published > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2012-09 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2012-09/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 25 February 2013. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > > Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From stolpe at resilans.se Mon Feb 25 16:12:32 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 16:12:32 +0100 (CET) Subject: [address-policy-wg] [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> References: <20130225132938.GS27968@x28.adm.denic.de> <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> Message-ID: On Mon, 25 Feb 2013, Erik Bais wrote: > Hi Daniel, > >> We see it quite often. And the answer is that the sponsorships is rather > an entry in some hidden RIPE db than a contract. When an end user is asked > "Do you have a sponsoring LIR for this resource and if so, who is it?", the > answer is usuallu " >> We have no idea". And the only way to be certain is to send an email to > the RIPE hostmasters. > > If you don't know, check the LIR Portal to see the registered PI spaces you > hold there. Well, not if it's legacy space, apparently. But it is an improvement that at least RIPE space is visable there now. As far as I can recall that wat not the case not very long ago. If you could really see everything via the LIR portal, then I agree the need for publication would be much smaller. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From sander at steffann.nl Tue Feb 26 14:32:15 2013 From: sander at steffann.nl (Sander Steffann) Date: Tue, 26 Feb 2013 14:32:15 +0100 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> Message-ID: <548479B2-6702-4182-9EEC-F96638D408E9@steffann.nl> > If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that. A lot more needs to be changed in internet routing before that becomes a viable option :-) Sander From ripe.address-policy-wg at ml.karotte.org Wed Feb 27 10:20:14 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 27 Feb 2013 10:20:14 +0100 Subject: [address-policy-wg] 2012-06 Proposal Accepted (Revert "Run Out Fairly") In-Reply-To: References: Message-ID: <20130227092014.GA1915@danton.fire-world.de> * Emilio Madaio [2013-02-18 15:09]: > > Dear Colleagues > > Consensus has been reached, and the proposal for a change to RIPE > Document ripe-577, "IPv4 Address Allocation and Assignment Policies > for the RIPE NCC Service Region", has been accepted by the RIPE > community. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2012-06 > > > The updated RIPE document is ripe-582 and is available at: > > https://www.ripe.net/ripe/docs/ripe-582 Hello, I just noticed that you should probably update ripe-488 / ripe-489 as well. They still mention the former assignment periods. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From mschmidt at ripe.net Wed Feb 27 14:08:15 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 27 Feb 2013 14:08:15 +0100 Subject: [address-policy-wg] 2012-09 Last Call for Comments (Modification of The Time Limits For Temporary Internet Assignments) Message-ID: Dear Colleagues, The proposal described in 2012-09, "Modification of The Time Limits For Temporary Internet Assignments", 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 27 March 2013 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 and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-09 Please e-mail any final comments about this proposal to apwg-chairs at ripe.net before 27 March 2013. Regards Marco Schmidt on behalf of the Policy Development Office RIPE NCC From andrea at ripe.net Wed Feb 27 14:23:53 2013 From: andrea at ripe.net (Andrea Cima) Date: Wed, 27 Feb 2013 14:23:53 +0100 Subject: [address-policy-wg] 2012-06 Proposal Accepted (Revert "Run Out Fairly") In-Reply-To: <20130227092014.GA1915@danton.fire-world.de> References: <20130227092014.GA1915@danton.fire-world.de> Message-ID: <512E08E9.5020803@ripe.net> Hi Sebastian, On 2/27/13 10:20 AM, Sebastian Wiesinger wrote: > * Emilio Madaio [2013-02-18 15:09]: >> Dear Colleagues >> >> Consensus has been reached, and the proposal for a change to RIPE >> Document ripe-577, "IPv4 Address Allocation and Assignment Policies >> for the RIPE NCC Service Region", has been accepted by the RIPE >> community. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2012-06 >> >> >> The updated RIPE document is ripe-582 and is available at: >> >> https://www.ripe.net/ripe/docs/ripe-582 > Hello, > > I just noticed that you should probably update ripe-488 / ripe-489 as > well. They still mention the former assignment periods. You are correct: ripe-488 and ripe-489 still mention the former assignment periods. This is because the RIPE NCC is currently implementing the policy proposal accepted on 18 February. As soon as the policy has been implemented we will inform the community. I hope this clarifies. Best regards, Andrea Cima RIPE NCC > Regards > > Sebastian > From Woeber at CC.UniVie.ac.at Wed Feb 27 15:42:50 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 27 Feb 2013 15:42:50 +0100 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> Message-ID: <512E1B6A.3040004@CC.UniVie.ac.at> Hi Alex, Alex Band wrote: [...] > As soon as the Registry is updated and the resources are associated with > the new holder, the LIR can optionally request a resource certificate for it. > This does mean that a transition is not seamless; there is a gap where there > is no certificate and no ROA, which has an effect on the RPKI validity state > of the associated BGP announcements. More on that below. Let's assume that there was a certificate for the full block of the current holder. Part of that space moves to a new holder. While it is "obvious", that there's no certificate for that space, it would also be "obvious", that the encompassing certificate would have to become invalid, e.g. by being revoked by the CA. Correct? If the answer is yes, such a transfer would endanger the routing stability of *both* parties? Wilfried. >>Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer. > > > The BGP announcement of a prefix will *not* be invalid in this case (a common misconception). There are three validity states of BGP announcements in relation to ROAs to consider: > > - valid (ROA exists) > - invalid (ROA exists for the prefix, but for a different ASN or max prefix length) > - unknown (no ROA exists for the prefix) > > So while a transfer is ongoing, the associated BGP announcements will be "unknown" because no ROA exists (yet). If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that. > > >>Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... ) > > > As said, the process is fully automated so no action is required from the transferring LIR. The LIR who receives the resources is free to request a certificate and create ROAs, if they so choose. > > Cheers, > > Alex From alexb at ripe.net Wed Feb 27 16:45:19 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 27 Feb 2013 16:45:19 +0100 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <512E1B6A.3040004@CC.UniVie.ac.at> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> <512E1B6A.3040004@CC.UniVie.ac.at> Message-ID: <421A013B-E07D-4AA6-9E95-0A58DC62DB87@ripe.net> On 27 Feb 2013, at 15:42, Wilfried Woeber wrote: > Hi Alex, > > Alex Band wrote: > > [...] >> As soon as the Registry is updated and the resources are associated with >> the new holder, the LIR can optionally request a resource certificate for it. >> This does mean that a transition is not seamless; there is a gap where there >> is no certificate and no ROA, which has an effect on the RPKI validity state >> of the associated BGP announcements. More on that below. > > Let's assume that there was a certificate for the full block of the current > holder. Part of that space moves to a new holder. While it is "obvious", that > there's no certificate for that space, it would also be "obvious", that the > encompassing certificate would have to become invalid, e.g. by being revoked > by the CA. Correct? No. If an LIR requested a resource certificate, it will at all times reflect the Registry. So if certain resources are added or removed from an LIR, a new, updated certificate is issued automatically to reflect the new situation, without user interaction required. So this applies for both parties if they had certification enabled. The only thing the receiving party would have to do is create a ROA for the new address space, to authorise the BGP announcement they will be doing with it. Until that time, the announcement will will remain with the "unknown" state (so NOT invalid). -Alex From nigel at titley.com Wed Feb 27 16:48:40 2013 From: nigel at titley.com (Nigel Titley) Date: Wed, 27 Feb 2013 15:48:40 +0000 Subject: [address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations In-Reply-To: <512E1B6A.3040004@CC.UniVie.ac.at> References: <51264C8B.3090502@inex.ie><51264817.3050101@inex.ie><791FC4F8-53A5-4C0B-98DF-6BFFA771BAD8@ripe.net> <512634A2.6000606@umn.edu> <20130221151207.GI51699@Space.Net> <1361464212.977961.611896183.282375.2@otrs.hostingconsult.ru> <1361476175.57719.3565185227.282375.2@otrs.hostingconsult.ru> <5129484C.3020002@titley.com> <862A73D42343AE49B2FC3C32FDDFE91C204D77FC@e2010-mbx-c1n1.exchange2010.nl> <09F8F6B7-1D2B-4DA4-9FB0-F963AA135D45@ripe.net> <512E1B6A.3040004@CC.UniVie.ac.at> Message-ID: <512E2AD8.5030604@titley.com> On 27/02/2013 14:42, Wilfried Woeber wrote: > Hi Alex, > > Alex Band wrote: > > [...] >> As soon as the Registry is updated and the resources are associated with >> the new holder, the LIR can optionally request a resource certificate for it. >> This does mean that a transition is not seamless; there is a gap where there >> is no certificate and no ROA, which has an effect on the RPKI validity state >> of the associated BGP announcements. More on that below. > Let's assume that there was a certificate for the full block of the current > holder. Part of that space moves to a new holder. While it is "obvious", that > there's no certificate for that space, it would also be "obvious", that the > encompassing certificate would have to become invalid, e.g. by being revoked > by the CA. Correct? > > If the answer is yes, such a transfer would endanger the routing stability of > *both* parties? > Yes, but from a practical point of view, the current holder will obtain a new certificate before relinquishing the partial block and the new holder will get a new certificate before using it. Nigel From gert at space.net Wed Feb 27 21:31:58 2013 From: gert at space.net (Gert Doering) Date: Wed, 27 Feb 2013 21:31:58 +0100 Subject: [address-policy-wg] 2012-09 Last Call for Comments (Modification of The Time Limits For Temporary Internet Assignments) In-Reply-To: <1361970595.19211@mobil.space.net> References: <1361970595.19211@mobil.space.net> Message-ID: <20130227203158.GG51699@Space.Net> Dear Working Group, On Wed, Feb 27, 2013 at 02:08:15PM +0100, Marco Schmidt wrote: > The proposal described in 2012-09, "Modification of The Time Limits For Temporary Internet Assignments", 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. well, technically we have not yet formally declared that (just in coordination e-mails between the WG chairs and the RIPE NCC PDO), so I now need to do so :-) 2012-09 saw a high amount of "support!" and "+1" voices in discussion phase, and no opposition, so moving to review phase was straightforward (there was a side-track discussion about "what is a month?" but that did not lead to changes in the text, or stated opposition). In review phase, things started slowly because we (chairs) didn't remind the WG that supporting voices do not carry over from the discussion phase. After I did that, we received 16 clear voices of support, and no opposing voices. So, we have quite strong consensus, and thus moved to Last Call. In Last Call, supporting voices do not need to be repeated - this is the phase where "silence is consent". But if you disagree with our interpretation of the comments in discussion or review phase, or with the propsal in general, now is the time to speak up. 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 (89) 32356-444 USt-IdNr.: DE813185279 From mschmidt at ripe.net Thu Feb 28 14:04:38 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 28 Feb 2013 14:04:38 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) Message-ID: Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-02/ We encourage you to review this proposal and send your comments to before 28 March 2013. Regards Marco Schmidt on behalf of the Policy Development Office RIPE NCC From james.blessing at despres.co.uk Thu Feb 28 14:31:28 2013 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 28 Feb 2013 13:31:28 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <1362057961_2903@mail.webtapestry.net> References: <1362057961_2903@mail.webtapestry.net> Message-ID: Support J On 28 February 2013 13:04, Marco Schmidt wrote: > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > -- James Blessing 07989 039 476 From slz at baycix.de Thu Feb 28 14:54:03 2013 From: slz at baycix.de (Sascha Lenz) Date: Thu, 28 Feb 2013 14:54:03 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <20130228131552.7EC302A016B@mx00.baycix.de> References: <20130228131552.7EC302A016B@mx00.baycix.de> Message-ID: <37CF8520-54E3-4C83-94F9-C0860430D1DA@baycix.de> Hi all, Am 28.02.2013 um 14:04 schrieb "Marco Schmidt" : > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > even though i actually liked the intention of the current policy text, there seems to be no choice here but to support this change due to the lack of a certification policy. I don't really want to go there again for a while. So, support. -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From Ragnar.Anfinsen at altibox.no Thu Feb 28 15:17:01 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Thu, 28 Feb 2013 14:17:01 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <74282b4f-58ba-49a4-92bd-e1d2213b0139@CH1EHSMHS019.ehs.local> References: <74282b4f-58ba-49a4-92bd-e1d2213b0139@CH1EHSMHS019.ehs.local> Message-ID: Support. No need of a policy text not being used. MVH/Regards Ragnar > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: 28. februar 2013 14:05 > To: policy-announce at ripe.net > Cc: apwg-chairs at ripe.net; address-policy-wg at ripe.net > Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of > requirement for certification of reallocated IPv4 addresses) > > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > From richih.mailinglist at gmail.com Thu Feb 28 15:25:00 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 28 Feb 2013 15:25:00 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <37CF8520-54E3-4C83-94F9-C0860430D1DA@baycix.de> References: <20130228131552.7EC302A016B@mx00.baycix.de> <37CF8520-54E3-4C83-94F9-C0860430D1DA@baycix.de> Message-ID: On Feb 28, 2013 2:54 PM, "Sascha Lenz" wrote: > even though i actually liked the intention of the current policy text, there > seems to be no choice here but to support this change due to the lack of a certification policy. Agreed. Support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcunningham at airspeed.ie Thu Feb 28 15:45:53 2013 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Thu, 28 Feb 2013 14:45:53 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: References: <1362057961_2903@mail.webtapestry.net> Message-ID: >> https://www.ripe.net/ripe/policies/proposals/2013-02/ Support. D. -- Donal Cunningham IP Network Engineer, AirSpeed Telecom dcunningham at airspeed.ie | +353 1 428 7531 From ripe.address-policy-wg at ml.karotte.org Thu Feb 28 16:06:06 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Thu, 28 Feb 2013 16:06:06 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <201302281321.r1SDL33P017725@danton.fire-world.de> References: <201302281321.r1SDL33P017725@danton.fire-world.de> Message-ID: <20130228150606.GA18782@danton.fire-world.de> * Marco Schmidt [2013-02-28 14:21]: > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ Support -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From mps31.ripe at gmail.com Thu Feb 28 16:37:20 2013 From: mps31.ripe at gmail.com (Mike Simkins) Date: Thu, 28 Feb 2013 15:37:20 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <512f5942.01cc0e0a.5a70.fffff1b6SMTPIN_ADDED_MISSING@mx.google.com> References: <512f5942.01cc0e0a.5a70.fffff1b6SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Support Mike. On 28 Feb 2013, at 13:04, Marco Schmidt wrote: > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC > > From pk at DENIC.DE Thu Feb 28 16:51:03 2013 From: pk at DENIC.DE (Peter Koch) Date: Thu, 28 Feb 2013 16:51:03 +0100 Subject: [address-policy-wg] [policy-announce] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: References: <74282b4f-58ba-49a4-92bd-e1d2213b0139@CH1EHSMHS019.ehs.local> Message-ID: <20130228155103.GE15921@x28.adm.denic.de> On Thu, Feb 28, 2013 at 02:17:01PM +0000, Anfinsen, Ragnar wrote: > Support. > > No need of a policy text not being used. abstain, but want to see whether my cross posting makes it to policy-announce. -Peter From lists-ripe at c4inet.net Thu Feb 28 19:00:33 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 28 Feb 2013 18:00:33 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <20130228131848.38A764EADF@mail.c4inet.net> References: <20130228131848.38A764EADF@mail.c4inet.net> Message-ID: <20130228180033.GA81592@cilantro.c4inet.net> On Thu, Feb 28, 2013 at 02:04:38PM +0100, Marco Schmidt wrote: >You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ Support. cheers, Sascha Luck From hamed at skydsl.ir Thu Feb 28 19:43:20 2013 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Thu, 28 Feb 2013 22:13:20 +0330 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <20130228180033.GA81592@cilantro.c4inet.net> References: <20130228131848.38A764EADF@mail.c4inet.net> <20130228180033.GA81592@cilantro.c4inet.net> Message-ID: Support Hamed Shafaghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Thu Feb 28 20:26:16 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 28 Feb 2013 20:26:16 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <512f593f.43b40e0a.0683.ffffe8a5SMTPIN_ADDED_MISSING@mx.google.com> References: <512f593f.43b40e0a.0683.ffffe8a5SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Feb 28, 2013 at 2:04 PM, Marco Schmidt wrote: > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ supported... -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From andreas.larsen at ip-only.se Thu Feb 28 20:27:55 2013 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Thu, 28 Feb 2013 20:27:55 +0100 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: Message-ID: Supported Den 2013-02-28 20:26 skrev Roger J?rgensen : >On Thu, Feb 28, 2013 at 2:04 PM, Marco Schmidt wrote: >> >> Dear Colleagues >> >> A new RIPE Policy Proposal has been made and is now available for >> discussion. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-02/ > >supported... > > > >-- > >Roger Jorgensen | ROJO9-RIPE >rogerj at gmail.com | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no > From Ragnar.Anfinsen at altibox.no Thu Feb 28 20:29:41 2013 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Thu, 28 Feb 2013 19:29:41 +0000 Subject: [address-policy-wg] [policy-announce] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <20130228155103.GE15921@x28.adm.denic.de> Message-ID: On 28.02.13 16:51, "Peter Koch" wrote: >On Thu, Feb 28, 2013 at 02:17:01PM +0000, Anfinsen, Ragnar wrote: >> Support. >> >> No need of a policy text not being used. > >abstain, but want to see whether my cross posting makes it to >policy-announce. Apologies for that. :) I was a bit quick on the reply button... /Ragnar From pk at DENIC.DE Thu Feb 28 21:09:04 2013 From: pk at DENIC.DE (Peter Koch) Date: Thu, 28 Feb 2013 21:09:04 +0100 Subject: [address-policy-wg] picky old f*rt confused by -announce [Re: [policy-announce] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses)] In-Reply-To: References: <20130228155103.GE15921@x28.adm.denic.de> Message-ID: <20130228200904.GC23218@x28.adm.denic.de> On Thu, Feb 28, 2013 at 07:29:41PM +0000, Anfinsen, Ragnar wrote: > >abstain, but want to see whether my cross posting makes it to > >policy-announce. > > Apologies for that. :) at best I shopuld apologize - this wasn't meant to put you on the spot. I'm sure the NCC postmaster will now fix the occasional leakage to a '-announce' list. -Peter From mueller at syr.edu Thu Feb 28 22:28:32 2013 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Feb 2013 21:28:32 +0000 Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of requirement for certification of reallocated IPv4 addresses) In-Reply-To: <201302281318.r1SDIaYW006180@mx2.syr.edu> References: <201302281318.r1SDIaYW006180@mx2.syr.edu> Message-ID: <855077AC3D7A7147A7570370CA01ECD235824E@SUEX10-mbx-10.ad.syr.edu> Support > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: Thursday, February 28, 2013 8:05 AM > To: policy-announce at ripe.net > Cc: apwg-chairs at ripe.net; address-policy-wg at ripe.net > Subject: [address-policy-wg] 2013-02 New Policy Proposal (Removal of > requirement for certification of reallocated IPv4 addresses) > > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-02/ > > We encourage you to review this proposal and send your comments to > before 28 March 2013. > > Regards > > Marco Schmidt > on behalf of the Policy Development Office > RIPE NCC >