From info at leadertelecom.ru Mon Aug 4 10:14:10 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 4 Aug 2014 12:14:10 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> Message-ID: <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> Hello all, I don't support this proposal. This is Pandora's box.? To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually.?If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur?annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom ? On 28 Jul 2014, at 20:18, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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: >> >>????[1]https://www.ripe.net/ripe/policies/proposals/2014-02 >> >> and the draft document at: >> >>????[2]https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal.??We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, >??APWG chair > > > Gert Doering >????????-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG????????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14??????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen?????????????????? HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444?????????? USt-IdNr.: DE813185279 ? [1] https://www.ripe.net/ripe/policies/proposals/2014-02 [2] https://www.ripe.net/ripe/policies/proposals/2014-02/draft -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon Aug 4 10:34:07 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 4 Aug 2014 10:34:07 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> Message-ID: <008d01cfafbe$df82ebe0$9e88c3a0$@a2b-internet.com> Hi Aleksei, This has nothing to do with cost or payment per IP. The policy is about keeping an accurate registry and not about how someone received the IP space in the past. The community doesn?t set cost / price for the NCC, that is discussed during the AGM. PI is here in the RIPE region because for some reason people didn?t require the option to assign IP space to others, but only use the IP space for themselves (their infrastructure). That is different than having PA space and being an LIR. On top of that, some organisations aren?t allowed by legal reasons to become a member, but they still have the requirement to be provider independent. Stating that LIR?s will be much worse off than owners of PI blocks is not true, because with the different status on the IP space, they have different rights / options. The main goal of the policy is to get the ?under the table? trading solved and keeping the registry accurate. The policy doesn?t change anything about what the cost is for PI (historic or future) and any discussion about cost/pricing should be done in member discussion / AGM. With this policy we will get the same transfer option for PI as we have for PA and that will allow us after this to go to a unified policy document just for transfers. Please let me know if you have additional questions. Regards, Erik Bais Author of 2014-02 Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens LeaderTelecom Ltd. Verzonden: maandag 4 augustus 2014 10:14 Aan: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] Hello all, I don't support this proposal. This is Pandora's box. To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually. If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom On 28 Jul 2014, at 20:18, Gert Doering > wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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/2014-02 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal. We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, > APWG chair > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefine at aramin.net Mon Aug 4 10:36:41 2014 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Mon, 04 Aug 2014 10:36:41 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> Message-ID: <53DF4619.5000908@aramin.net> PI and PA are for different purposes. PA are for ISP's, who give ip's for customers. I cooperate with two ip owners. One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). Here is used PI class. I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. Paying by both common "lir fee" would be unfair. If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: > Hello all, > > I don't support this proposal. > > This is Pandora's box. > > To get 1024 IPs for now company can register LIR and pay to RIPE 2000 > eur + 1600 eur annually. If same company will transfer PI, then they > will pay to RIPE only 50 eur. > > LIR's will be in much worse situation than owners of PI-networks. > > We can apply proposal if we will increase payment for PI-networks > after transfer. For example, 1000 eur annually for each PI resource. > In this situation new LIRs and owners of PI-network will pay into RIPE > NCC similar payments. > > -- > Aleksei Ivanov > LeaderTelecom > > On 28 Jul 2014, at 20:18, Gert Doering wrote: > > > Dear AP WG, > > > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > >> The draft document for the proposal described in 2014-02, > >> "Allow IPv4 PI transfer" 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/2014-02 > >> > >> and the draft document at: > >> > >> https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > > > > We could use a bit more input on this proposal. We have one clear > > statement of support, and one mail that puts up some questions while not > > taking a clear pro/con position - and that is not enough to declare > > anything except "needs more time" at the end of review phase. > > > > So, tell me your thoughts, please. > > > > thanks, > > > > Gert Doering, > > APWG chair > > > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Mon Aug 4 10:54:32 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 4 Aug 2014 12:54:32 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF4619.5000908@aramin.net> References: <53DF4619.5000908@aramin.net> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> Message-ID: <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> Dear?Andrzej, >?PI and PA are for different purposes. > PA are for ISP's, who give ip's for customers. Yes, this is great theory. In fact people ask - why I have to pay for LIR? PI is cheaper for me. I will use IPs as I need.? I see a lot of requests for PI networks last month. They ready to pay for transfer one time and then pay very small money every year.? >?Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) I remember very long discussion about it ) We decided that each LIR is a member and we contribute same amount of money into RIPE. And it is logicaly. ? -- Aleksei 04.08.2014 12:37 - Andrzej Dopiera?a ???????(?): PI and PA are for different purposes. PA are for ISP's, who give ip's for customers. I cooperate with two ip owners. One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). Here is used PI class. I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. Paying by both common "lir fee" would be unfair. If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: Hello all, I don't support this proposal. This is Pandora's box.? To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually.?If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur?annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom ? On 28 Jul 2014, at 20:18, Gert Doering [1] wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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: >> >>????[2]https://www.ripe.net/ripe/policies/proposals/2014-02 >> >> and the draft document at: >> >>????[3]https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal.??We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, >??APWG chair > > > Gert Doering >????????-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG????????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14??????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen?????????????????? HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444?????????? USt-IdNr.: DE813185279 ? -- Regards, Andrzej 'The Undefined' Dopiera?a [4]http://andrzej.dopierala.name/ [1] mailto:gert at space.net [2] https://www.ripe.net/ripe/policies/proposals/2014-02 [3] https://www.ripe.net/ripe/policies/proposals/2014-02/draft [4] http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From noable at gmail.com Mon Aug 4 11:04:37 2014 From: noable at gmail.com (Andrei Kushnireuski) Date: Mon, 4 Aug 2014 11:04:37 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> References: <53DF4619.5000908@aramin.net> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> Message-ID: Everybody knows a lot of ISPs use PI at result of non-ideal IPv4 assignment policy from the RIPE NCC side. The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. -- Andrei Kushnireuski On 04 Aug 2014, at 10:54, LeaderTelecom Ltd. wrote: > Dear Andrzej, > > > PI and PA are for different purposes. > > PA are for ISP's, who give ip's for customers. > > Yes, this is great theory. > > In fact people ask - why I have to pay for LIR? PI is cheaper for me. I will use IPs as I need. > I see a lot of requests for PI networks last month. They ready to pay for transfer one time and then pay very small money every year. > > > Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) > > I remember very long discussion about it ) We decided that each LIR is a member and we contribute same amount of money into RIPE. And it is logicaly. > > -- > Aleksei > > 04.08.2014 12:37 - Andrzej Dopiera?a ???????(?): > PI and PA are for different purposes. > PA are for ISP's, who give ip's for customers. > I cooperate with two ip owners. > One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. > > Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. > > And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). > Here is used PI class. > > I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. > > Paying by both common "lir fee" would be unfair. > > If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? > > Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) > > W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: > > Hello all, > > I don't support this proposal. > > This is Pandora's box. > > To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually. If same company will transfer PI, then they will pay to RIPE only 50 eur. > > LIR's will be in much worse situation than owners of PI-networks. > > We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. > > -- > Aleksei Ivanov > LeaderTelecom > > > On 28 Jul 2014, at 20:18, Gert Doering wrote: > > > Dear AP WG, > > > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > >> The draft document for the proposal described in 2014-02, > >> "Allow IPv4 PI transfer" 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/2014-02 > >> > >> and the draft document at: > >> > >> https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > > > > We could use a bit more input on this proposal. We have one clear > > statement of support, and one mail that puts up some questions while not > > taking a clear pro/con position - and that is not enough to declare > > anything except "needs more time" at the end of review phase. > > > > So, tell me your thoughts, please. > > > > thanks, > > > > Gert Doering, > > APWG chair > > > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > -- > Regards, > Andrzej 'The Undefined' Dopiera?a > http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon Aug 4 11:15:24 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 4 Aug 2014 11:15:24 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF4619.5000908@aramin.net> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> Message-ID: <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> Hi Andrzej, This is getting off-topic to the mentioned policy, but I will answer your question. > If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? > Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) That would have a tax implication for the RIPE NCC and that is one of the reasons why the members votes 2 years ago to a simpler fixed fee structure. As you might know the charging schema was pretty complex in the past. Regards, Erik Bais Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens Andrzej Dopierala Verzonden: maandag 4 augustus 2014 10:37 Aan: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] PI and PA are for different purposes. PA are for ISP's, who give ip's for customers. I cooperate with two ip owners. One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). Here is used PI class. I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. Paying by both common "lir fee" would be unfair. If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: Hello all, I don't support this proposal. This is Pandora's box. To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually. If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom On 28 Jul 2014, at 20:18, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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/2014-02 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal. We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, > APWG chair > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ From gert at space.net Mon Aug 4 11:20:07 2014 From: gert at space.net (Gert Doering) Date: Mon, 4 Aug 2014 11:20:07 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: References: <53DF4619.5000908@aramin.net> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> Message-ID: <20140804092007.GG51793@Space.Net> Hi, On Mon, Aug 04, 2014 at 11:04:37AM +0200, Andrei Kushnireuski wrote: > Everybody knows a lot of ISPs use PI at result of non-ideal IPv4 assignment policy from the RIPE NCC side. I should point out that the policy is not made by the RIPE NCC but by *this* community. The "PI loophole for IPv4 ISPs" was pointed out a few times by people from the NCC, and the community did not want to change it - so don't blaim the NCC for it. > The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. Cost is out of scope for the address policy WG. PI -> PA conversion can be done today already, if a PI holder is or becomes a LIR - but that's a different thing than what is under discussion of this proposal. So it would be good to stay focused, and not discuss everything that has gone wrong with IPv4 in this thread. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From undefine at aramin.net Mon Aug 4 11:26:59 2014 From: undefine at aramin.net (=?UTF-8?B?QW5kcnplaiBEb3BpZXJhxYJh?=) Date: Mon, 04 Aug 2014 11:26:59 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> Message-ID: <53DF51E3.4070503@aramin.net> Yes. It was complex, because membership to specific class depend on years of ip owning, date, other lirs etc. It was stupid. It was because amount of ip owned by RIPE was not fixed. "the best" is simple structure. For example - every lir who give ip for others - pay 1600e, every pi owner who use ip for infrastructure pay 50e (like now) - every ip owner (independly pi or pa) pay the same amound of money for every ip which have both are simple. And second is better. In first schema - get a thought experiment - what would happen if all lirs merged together. If they would pay 1600euro (like in 1 scenario) - total ripe income would be 1600euro. much to low for ripe. In second scenario - income of ripe (ncc) aren't depended on count of lirs, but on amount of owned ip's. currenty there is no new ip's, so dependende the payment from date of grant is senseless. W dniu 04.08.2014 11:15, Erik Bais pisze: > Hi Andrzej, > > This is getting off-topic to the mentioned policy, but I will answer your question. > >> If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? >> Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) > That would have a tax implication for the RIPE NCC and that is one of the reasons why the members votes 2 years ago to a simpler fixed fee structure. > As you might know the charging schema was pretty complex in the past. > > Regards, > Erik Bais > > > Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens Andrzej Dopierala > Verzonden: maandag 4 augustus 2014 10:37 > Aan: address-policy-wg at ripe.net > Onderwerp: Re: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] > > PI and PA are for different purposes. > PA are for ISP's, who give ip's for customers. > I cooperate with two ip owners. > One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. > > Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. > > And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). > Here is used PI class. > > I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. > > Paying by both common "lir fee" would be unfair. > > If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? > > Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) > > W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: > Hello all, > > I don't support this proposal. > > This is Pandora's box. > > To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually. If same company will transfer PI, then they will pay to RIPE only 50 eur. > > LIR's will be in much worse situation than owners of PI-networks. > > We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. > > -- > Aleksei Ivanov > LeaderTelecom > > > On 28 Jul 2014, at 20:18, Gert Doering wrote: > >> Dear AP WG, >> >> On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >>> The draft document for the proposal described in 2014-02, >>> "Allow IPv4 PI transfer" 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/2014-02 >>> >>> and the draft document at: >>> >>> https://www.ripe.net/ripe/policies/proposals/2014-02/draft >> >> We could use a bit more input on this proposal. We have one clear >> statement of support, and one mail that puts up some questions while not >> taking a clear pro/con position - and that is not enough to declare >> anything except "needs more time" at the end of review phase. >> >> So, tell me your thoughts, please. >> >> thanks, >> >> Gert Doering, >> APWG chair >> >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ From ripe at opteamax.de Mon Aug 4 11:37:23 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Mon, 04 Aug 2014 11:37:23 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF51E3.4070503@aramin.net> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> Message-ID: <53DF5453.4000706@opteamax.de> On 04.08.2014 11:26, Andrzej Dopiera?a wrote: > Yes. It was complex, because membership to specific class depend on > years of ip owning, date, other lirs etc. > It was stupid. > > It was because amount of ip owned by RIPE was not fixed. > > "the best" is simple structure. For example > - every lir who give ip for others - pay 1600e, every pi owner who use > ip for infrastructure pay 50e (like now) > - every ip owner (independly pi or pa) pay the same amound of money for > every ip which have > > both are simple. > And second is better. In first schema - get a thought experiment - what > would happen if all lirs merged together. If they would pay 1600euro > (like in 1 scenario) - total ripe income would be 1600euro. much to low > for ripe. > In second scenario - income of ripe (ncc) aren't depended on count of > lirs, but on amount of owned ip's. > currenty there is no new ip's, so dependende the payment from date of > grant is senseless. And actually your proposed kind of charging-scheme is working pretty well for other RIR, Full support from me, and I am sure, that charging yearly per IP would lead to a return of a not to little amount of IPv4 - in my guess at least one /8 - which some old LIR simply hold without using it simply to maybe make some profit by selling it somewhen, and because these IPs do currently not cost anything. ... but as Gerd already mentioned, that's not to be discussed here, as it is not address-policy discussion. BR Jens -- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From gert at space.net Mon Aug 4 11:46:18 2014 From: gert at space.net (Gert Doering) Date: Mon, 4 Aug 2014 11:46:18 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF51E3.4070503@aramin.net> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> Message-ID: <20140804094618.GH51793@Space.Net> Hi, On Mon, Aug 04, 2014 at 11:26:59AM +0200, Andrzej Dopiera??a wrote: > "the best" is simple structure. For example > - every lir who give ip for others - pay 1600e, every pi owner who use > ip for infrastructure pay 50e (like now) > - every ip owner (independly pi or pa) pay the same amound of money for > every ip which have As said before, APWG has very little influence on the charging scheme. So please keep prices out of this discussion here - charging scheme and RIPE fees can be discussed on the ripe-members list. thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From info at leadertelecom.ru Mon Aug 4 12:41:01 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 4 Aug 2014 14:41:01 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: References: <53DF4619.5000908@aramin.net> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> Message-ID: <1407148860.202513.741917362.538390.2@otrs.hostingconsult.ru> Dear?Andrei, >?The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. Very good solution. All PI convert to PA. As a result memebership fee will be less in 2 times or more while we will have at least in 2 times more RIPE members. -- Aleksei 04.08.2014 13:05 - Andrei Kushnireuski ???????(?): Everybody knows a lot of ISPs use PI at result of non-ideal IPv4 assignment policy from the RIPE NCC side. ? The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. -- Andrei Kushnireuski ? On 04 Aug 2014, at 10:54, LeaderTelecom Ltd. <[1]info at leadertelecom.ru> wrote: Dear?Andrzej, >?PI and PA are for different purposes. > PA are for ISP's, who give ip's for customers. Yes, this is great theory. In fact people ask - why I have to pay for LIR? PI is cheaper for me. I will use IPs as I need.? I see a lot of requests for PI networks last month. They ready to pay for transfer one time and then pay very small money every year.? >?Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) I remember very long discussion about it ) We decided that each LIR is a member and we contribute same amount of money into RIPE. And it is logicaly. ? -- Aleksei 04.08.2014 12:37 - Andrzej Dopiera?a ???????(?): PI and PA are for different purposes. PA are for ISP's, who give ip's for customers. I cooperate with two ip owners. One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). Here is used PI class. I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. Paying by both common "lir fee" would be unfair. If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: Hello all, I don't support this proposal. This is Pandora's box.? To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually.?If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur?annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom ? On 28 Jul 2014, at 20:18, Gert Doering [2] wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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: >> >>????[3]https://www.ripe.net/ripe/policies/proposals/2014-02 >> >> and the draft document at: >> >>????[4]https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal.??We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, >??APWG chair > > > Gert Doering >????????-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG????????????????????????Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14??????????Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen?????????????????? HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444?????????? USt-IdNr.: DE813185279 ? -- Regards, Andrzej 'The Undefined' Dopiera?a [5]http://andrzej.dopierala.name/ ? [1] mailto:info at leadertelecom.ru [2] mailto:gert at space.net [3] https://www.ripe.net/ripe/policies/proposals/2014-02 [4] https://www.ripe.net/ripe/policies/proposals/2014-02/draft [5] http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Mon Aug 4 13:20:09 2014 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 04 Aug 2014 13:20:09 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <20140804094618.GH51793@Space.Net> References: <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> Message-ID: <53DF6C69.4080302@danysek.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Membership fee at these times doesn't in any case correlate with ammount of address resources held by each LIR. Conversely, fees were simplified. - From APWG perspective, I *support* this proposal. It doesn't change almost anything in practice - as new IPv4 PI aren't assigned, this just affects existing assignments. With regards, Daniel On 4.8.2014 11:46, Gert Doering wrote: > Hi, > > On Mon, Aug 04, 2014 at 11:26:59AM +0200, Andrzej Dopiera??a > wrote: >> "the best" is simple structure. For example - every lir who give >> ip for others - pay 1600e, every pi owner who use ip for >> infrastructure pay 50e (like now) - every ip owner (independly pi >> or pa) pay the same amound of money for every ip which have > > As said before, APWG has very little influence on the charging > scheme. > > So please keep prices out of this discussion here - charging scheme > and RIPE fees can be discussed on the ripe-members list. > > thanks, > > Gert Doering -- APWG chair > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPfbGcACgkQ0m6yQqKjWoJoAgCfbkg+0rfky7vca9FMDNYzzp7e ZZ8An1UGqAFWdZqyNnatvYM+qa9TNHNp =yQF1 -----END PGP SIGNATURE----- From info at leadertelecom.ru Mon Aug 4 13:40:50 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 4 Aug 2014 15:40:50 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF6C69.4080302@danysek.cz> References: <53DF6C69.4080302@danysek.cz> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> Message-ID: <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> Dear Daniel, > - It doesn't change > almost anything in practice - as new IPv4 PI aren't assigned, this > just affects existing assignments. It can drop amount of LIRs, while much cheaper to find PI - pay one time fee to owner and then return PA space and cancel contract as LIR. I understund difference PA & PI, but as I told - real customers often uses PI as PA. ? -- Aleksei LeaderTelecom 04.08.2014 15:29 - Daniel Suchy ???????(?): -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Membership fee at these times doesn't in any case correlate with ammount of address resources held by each LIR. Conversely, fees were simplified. - From APWG perspective, I *support* this proposal. It doesn't change almost anything in practice - as new IPv4 PI aren't assigned, this just affects existing assignments. With regards, Daniel On 4.8.2014 11:46, Gert Doering wrote: > Hi, > > On Mon, Aug 04, 2014 at 11:26:59AM +0200, Andrzej Dopiera??a > wrote: >> "the best" is simple structure. For example - every lir who give >> ip for others - pay 1600e, every pi owner who use ip for >> infrastructure pay 50e (like now) - every ip owner (independly pi >> or pa) pay the same amound of money for every ip which have > > As said before, APWG has very little influence on the charging > scheme. > > So please keep prices out of this discussion here - charging scheme > and RIPE fees can be discussed on the ripe-members list. > > thanks, > > Gert Doering -- APWG chair > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPfbGcACgkQ0m6yQqKjWoJoAgCfbkg+0rfky7vca9FMDNYzzp7e ZZ8An1UGqAFWdZqyNnatvYM+qa9TNHNp =yQF1 -----END PGP SIGNATURE----- ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Mon Aug 4 13:58:58 2014 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 04 Aug 2014 13:58:58 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> References: <53DF6C69.4080302@danysek.cz> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> Message-ID: <53DF7582.3040306@danysek.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4.8.2014 13:40, LeaderTelecom Ltd. wrote: > It can drop amount of LIRs, while much cheaper to find PI - pay > one time fee to owner and then return PA space and cancel contract > as LIR. I understund difference PA & PI, but as I told - real > customers often uses PI as PA. Number of (free and available) PI resources is quite low and it remains I think - simply due to depletion. I don't think we need another administrative barriers to use existing assigned address space. Misuse of some address space assignment is question of assignment audit in general, I think. Transfer in general points attention to particular LIR/address space during administrative procedure. And as was mentioned by Gert, in APWG we basicaly haven't any reason to care about NCC charging scheme, this is discussion for another mailing list. - - Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPfdX8ACgkQ0m6yQqKjWoJjtACeM21U97y3qQexIslVJdTwT/Pc Hu0AnirIBJdJeYtNyuyyQZZhZUyaNAht =xxZu -----END PGP SIGNATURE----- From ak at list.ak.cx Mon Aug 4 13:59:38 2014 From: ak at list.ak.cx (Andre Keller) Date: Mon, 04 Aug 2014 13:59:38 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> References: <53DF6C69.4080302@danysek.cz> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> Message-ID: <53DF75AA.4000604@list.ak.cx> Hi Aleksei, On 08/04/2014 01:40 PM, LeaderTelecom Ltd. wrote: > It can drop amount of LIRs, while much cheaper to find PI - pay one time fee > to owner and then return PA space and cancel contract as LIR. I understund > difference PA & PI, but as I told - real customers often uses PI as PA. This might work for IPv4 - you will violate policies if you still address end-users with these addresses and risk de-registration. But for IPv6 this is a different story. Getting IPv6 PI space in a block that is greater than /48 you need to provide documentation. And I doubt you can "fake" documentiation that will give you the resources you need. If all your competitors give customers a /48 you will want to do that as-well. Or even with /56, there are only 256 of those in a /48. So if you want to participate in the market you we'll need PA IPv6 and therefore need to be a LIR anyway. What is ~1300? in your yearly budget compared to equipment, transit/backhaul and operating costs? I would not think it is significant... g Andre From Piotr.Strzyzewski at polsl.pl Mon Aug 4 14:30:21 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 4 Aug 2014 14:30:21 +0200 Subject: [address-policy-wg] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer) In-Reply-To: <20140728181853.GA48371@Space.Net> References: <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> Message-ID: <20140804123021.GC29660@hydra.ck.polsl.pl> On Mon, Jul 28, 2014 at 08:18:53PM +0200, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > > The draft document for the proposal described in 2014-02, > > "Allow IPv4 PI transfer" 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/2014-02 > > > > and the draft document at: > > > > https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal. We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. I support this proposal. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From ebais at a2b-internet.com Mon Aug 4 14:47:47 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 4 Aug 2014 14:47:47 +0200 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <1407148860.202513.741917362.538390.2@otrs.hostingconsult.ru> References: <53DF4619.5000908@aramin.net> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <1407142471.572679.772198449.538390.2@otrs.hostingconsult.ru> <1407148860.202513.741917362.538390.2@otrs.hostingconsult.ru> Message-ID: <012201cfafe2$4f6b8570$ee429050$@a2b-internet.com> For those that might have missed the discussion on this mailing list about the policy proposal or didn?t attend RIPE68, I have done a presentation in Warshaw at RIPE68 about the policy proposal. These options have been discussed there and you can review the discussion on the archive here : https://ripe68.ripe.net/archives/video/167/ Regards, Erik Bais Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens LeaderTelecom Ltd. Verzonden: maandag 4 augustus 2014 12:41 Aan: noable at gmail.com CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] Dear Andrei, > The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. Very good solution. All PI convert to PA. As a result memebership fee will be less in 2 times or more while we will have at least in 2 times more RIPE members. -- Aleksei 04.08.2014 13:05 - Andrei Kushnireuski ???????(?): Everybody knows a lot of ISPs use PI at result of non-ideal IPv4 assignment policy from the RIPE NCC side. The single solution is to make PI cost = PA cost and allow ISP to move PI > PA without additional problems. -- Andrei Kushnireuski On 04 Aug 2014, at 10:54, LeaderTelecom Ltd. > wrote: Dear Andrzej, > PI and PA are for different purposes. > PA are for ISP's, who give ip's for customers. Yes, this is great theory. In fact people ask - why I have to pay for LIR? PI is cheaper for me. I will use IPs as I need. I see a lot of requests for PI networks last month. They ready to pay for transfer one time and then pay very small money every year. > Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) I remember very long discussion about it ) We decided that each LIR is a member and we contribute same amount of money into RIPE. And it is logicaly. -- Aleksei 04.08.2014 12:37 - Andrzej Dopiera?a ???????(?): PI and PA are for different purposes. PA are for ISP's, who give ip's for customers. I cooperate with two ip owners. One - is ISP. Give ip, block of ip for customers (on lans, in collocations etc). It's LIR. Second - is voip provider. Need stable links from differend upstreams, with BGP. Don't give ip for cusomers. IP's are used only for own infrastructure - SIP proxy, registrars, application services, www with SSL, VPNS's etc. And need stable ip's, because changing ip's in customers is extremaly hardly (they have ipsecs, firewalls etc). Here is used PI class. I think puting both ip owners in one bag is misteake. First - use thousands of ip's. For second - /24 is enought forever. Paying by both common "lir fee" would be unfair. If we want to be fair - why not pay for every used ip? why shouldn't pay 100E every /24 block? Then - PI owner with /24 block would pay 100E. And ISP with /18 would pay 64 *100E = 6400E ? :) W dniu 04.08.2014 10:14, LeaderTelecom Ltd. pisze: Hello all, I don't support this proposal. This is Pandora's box. To get 1024 IPs for now company can register LIR and pay to RIPE 2000 eur + 1600 eur annually. If same company will transfer PI, then they will pay to RIPE only 50 eur. LIR's will be in much worse situation than owners of PI-networks. We can apply proposal if we will increase payment for PI-networks after transfer. For example, 1000 eur annually for each PI resource. In this situation new LIRs and owners of PI-network will pay into RIPE NCC similar payments. -- Aleksei Ivanov LeaderTelecom On 28 Jul 2014, at 20:18, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >> The draft document for the proposal described in 2014-02, >> "Allow IPv4 PI transfer" 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/2014-02 >> >> and the draft document at: >> >> https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal. We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, > APWG chair > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -- Regards, Andrzej 'The Undefined' Dopiera?a http://andrzej.dopierala.name/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Tue Aug 5 08:47:27 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 5 Aug 2014 10:47:27 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF75AA.4000604@list.ak.cx> References: <53DF75AA.4000604@list.ak.cx> <53DF6C69.4080302@danysek.cz> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> Message-ID: <1407221246.435832.884960473.538390.2@otrs.hostingconsult.ru> Dear?Andre, > This might work for IPv4 - you will violate policies if you still > address end-users with these addresses and risk de-registration.? Do you know any fact of de-registration?? > But for?IPv6 this is a different story. Getting IPv6 PI space in a block that is > greater than /48 you need to provide documentation. And I doubt you can > "fake" documentiation that will give you the resources you need. If all > your competitors give customers a /48 you will want to do that as-well. > Or even with /56, there are only 256 of those in a /48. So if you want > to participate in the market you we'll need PA IPv6 and therefore need > to be a LIR anyway. IPv6 is another story. We charge very small money for IPv6 network and customers usualy use IPv6 in right way. >?What is ~1300? in your yearly budget compared to equipment, > transit/backhaul and operating costs? I would not think it is significant... Some startups have very low amount of money.? ? -- Aleksei 04.08.2014 15:59 - Andre Keller ???????(?): Hi Aleksei, On 08/04/2014 01:40 PM, LeaderTelecom Ltd. wrote: > It can drop amount of LIRs, while much cheaper to find PI - pay one time fee > to owner and then return PA space and cancel contract as LIR. I understund > difference PA & PI, but as I told - real customers often uses PI as PA.???? This might work for IPv4 - you will violate policies if you still address end-users with these addresses and risk de-registration. But for IPv6 this is a different story. Getting IPv6 PI space in a block that is greater than /48 you need to provide documentation. And I doubt you can "fake" documentiation that will give you the resources you need. If all your competitors give customers a /48 you will want to do that as-well. Or even with /56, there are only 256 of those in a /48. So if you want to participate in the market you we'll need PA IPv6 and therefore need to be a LIR anyway. What is ~1300? in your yearly budget compared to equipment, transit/backhaul and operating costs? I would not think it is significant... g Andre ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Tue Aug 5 08:56:44 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 5 Aug 2014 10:56:44 +0400 Subject: [address-policy-wg] [Ticket#2014072901004581] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer [...] In-Reply-To: <53DF7582.3040306@danysek.cz> References: <53DF7582.3040306@danysek.cz> <53DF6C69.4080302@danysek.cz> <18E4E1D4-9F0C-46C2-A18A-4B37BA8BDFF5@cerezo.org> <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <1407140049.456336.452477687.538390.2@otrs.hostingconsult.ru> <53DF4619.5000908@aramin.net> <009c01cfafc4$a36ca190$ea45e4b0$@a2b-internet.com> <53DF51E3.4070503@aramin.net> <20140804094618.GH51793@Space.Net> <1407152449.958651.355918516.538390.2@otrs.hostingconsult.ru> Message-ID: <1407221803.161461.577481482.538390.2@otrs.hostingconsult.ru> Dear?Daniel, > Number of (free and available) PI resources is quite low and it > remains I think - simply due to depletion. I don't think we need > another administrative barriers to use existing assigned address space. If?Number of (free and available) PI resources is quite low, then we will not have any problem, but I afraid that a lot of PI resources can be free. For example, some companies already transfered 1mln free IPv4 addresses (QSC AG): https://www.linkedin.com/today/post/article/20140801190343-6692786-secrets-of-ipv4-transfers-in-ripe-region?trk=mp-edit-rr-posts ? -- Aleksei Ivanov LeaderTelecom 04.08.2014 15:59 - Daniel Suchy ???????(?): -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4.8.2014 13:40, LeaderTelecom Ltd. wrote: > It can drop amount of LIRs, while much cheaper to find PI - pay > one time fee to owner and then return PA space and cancel contract > as LIR. I understund difference PA & PI, but as I told - real > customers often uses PI as PA. Number of (free and available) PI resources is quite low and it remains I think - simply due to depletion. I don't think we need another administrative barriers to use existing assigned address space. Misuse of some address space assignment is question of assignment audit in general, I think. Transfer in general points attention to particular LIR/address space during administrative procedure. And as was mentioned by Gert, in APWG we basicaly haven't any reason to care about NCC charging scheme, this is discussion for another mailing list. - - Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPfdX8ACgkQ0m6yQqKjWoJjtACeM21U97y3qQexIslVJdTwT/Pc Hu0AnirIBJdJeYtNyuyyQZZhZUyaNAht =xxZu -----END PGP SIGNATURE----- ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From af at ins.de Tue Aug 5 10:29:09 2014 From: af at ins.de (Andreas Frackowiak) Date: Tue, 05 Aug 2014 10:29:09 +0200 Subject: [address-policy-wg] [ncc-services-wg] Crimea papers In-Reply-To: <53DA22CE.20506@netassist.ua> References: <53D65628.6010001@ukraine.su> <53D66B6A.3060002@ripe.net> <53D68EF8.2060103@ukraine.su> <20140728180451.GC51793@Space.Net> <20140729073316.GJ51793@Space.Net> <53D75403.3080902@netassist.ua> <20140729092156.GM51793@Space.Net> <29BD1EF7-5F1A-47BE-9960-2F36DD21C01A@rfc1035.com> <7C28157D-633E-45BC-8855-4B3864CC436A@bondis.org> <53DA22CE.20506@netassist.ua> Message-ID: <53E095D5.8000500@ins.de> Hi, Am 31.07.2014 13:04, schrieb ksyu at netassist.ua: > lets see this article > > http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.226.01.0002.01.ENG Interesting. ------------ 2.Annex III shall include key equipment and technology related to the creation, acquisition or development of infrastructure in the following sectors: (..) (b) telecommunications; (...) (...) 3.It shall be prohibited to: (a)provide, directly or indirectly, technical assistance or brokering services related to the key equipment and technology listed in Annex III, or related to the provision, manufacture, maintenance and use of items listed in Annex III to any natural or legal person, entity or body in Crimea or Sevastopol or for use in Crimea or Sevastopol; and (...) --------------- To my understanding, IP-numbers are kind of "key technology" for telecommunications and so the RIPE services shall fall under this EU directive. However, Annex III does not list (yet) anything directly IP related, so the RIPE sevices seem not to fall unders this EU directive. Someone should tell the EU, that this new internet-thingy is kind of a key technology for telecommunications. I do not think that RIPE should make its own policy/politics in this issue but should just follow the law. Greetings Andreas > 29.07.2014 16:45, Richard Hartmann ?????: >> Dmitriy, all, >> >> >> as has been stated repeatedly, this is not the place for this discussion. >> >> The initial question was "will RIPE NCC hand resources to a LIR in >> Crimea, based on Russian papers" and the clear answer is "if said >> papers establish the existence of the LIR and substantiate the LIR's >> claims, yes". -- INS GmbH www.ins.de Gaswerkstra?e 64 D-44575 Castrop-Rauxel Tel: +49 2305 101 0 Fax: +49 2305 101 155 Gesch?ftsf?hrung: Andreas Frackowiak Alle Angebote sind unverbindlich. AG Dortmund: HRB 17064 From turchanyi.geza at gmail.com Wed Aug 6 12:44:53 2014 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Wed, 6 Aug 2014 12:44:53 +0200 Subject: [address-policy-wg] [ncc-services-wg] Crimea papers In-Reply-To: <53E095D5.8000500@ins.de> References: <53D65628.6010001@ukraine.su> <53D66B6A.3060002@ripe.net> <53D68EF8.2060103@ukraine.su> <20140728180451.GC51793@Space.Net> <20140729073316.GJ51793@Space.Net> <53D75403.3080902@netassist.ua> <20140729092156.GM51793@Space.Net> <29BD1EF7-5F1A-47BE-9960-2F36DD21C01A@rfc1035.com> <7C28157D-633E-45BC-8855-4B3864CC436A@bondis.org> <53DA22CE.20506@netassist.ua> <53E095D5.8000500@ins.de> Message-ID: Andreas, I think you perfectly understand that the RIPE services are not restricted by this EU directive. And this is GOOD. Why shall anybody create a hole in the map? A hole in the map would create less conflicts or more??? Allowing people talk to others creates less danger than not allowing! Thanks, G?za On Tue, Aug 5, 2014 at 10:29 AM, Andreas Frackowiak wrote: > Hi, > > Am 31.07.2014 13:04, schrieb ksyu at netassist.ua: > > lets see this article > > > > > http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.226.01.0002.01.ENG > > Interesting. > > ------------ > 2.Annex III shall include key equipment and technology related to the > creation, acquisition or development of infrastructure in the following > sectors: (..) (b) telecommunications; (...) > > (...) > 3.It shall be prohibited to: > > (a)provide, directly or indirectly, technical assistance or brokering > services related to the key equipment and technology listed in Annex > III, or related to the provision, manufacture, maintenance and use of > items listed in Annex III to any natural or legal person, entity or body > in Crimea or Sevastopol or for use in Crimea or Sevastopol; and > (...) > --------------- > > To my understanding, IP-numbers are kind of "key technology" for > telecommunications and so the RIPE services shall fall under this EU > directive. > > However, Annex III does not list (yet) anything directly IP related, > so the RIPE sevices seem not to fall unders this EU directive. > > Someone should tell the EU, that this new internet-thingy is kind of a > key technology for telecommunications. > > I do not think that RIPE should make its own policy/politics in this > issue but should just follow the law. > > Greetings > Andreas > > > > 29.07.2014 16:45, Richard Hartmann ?????: > >> Dmitriy, all, > >> > >> > >> as has been stated repeatedly, this is not the place for this > discussion. > >> > >> The initial question was "will RIPE NCC hand resources to a LIR in > >> Crimea, based on Russian papers" and the clear answer is "if said > >> papers establish the existence of the LIR and substantiate the LIR's > >> claims, yes". > > -- > INS GmbH www.ins.de > Gaswerkstra?e 64 D-44575 Castrop-Rauxel > Tel: +49 2305 101 0 Fax: +49 2305 101 155 > Gesch?ftsf?hrung: Andreas Frackowiak > Alle Angebote sind unverbindlich. AG Dortmund: HRB 17064 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe.address-policy-wg at ml.karotte.org Thu Aug 7 10:13:15 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Thu, 7 Aug 2014 10:13:15 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <201407311142.s6VBg41H011677@danton.fire-world.de> References: <201407311142.s6VBg41H011677@danton.fire-world.de> Message-ID: <20140807081314.GC4863@danton.fire-world.de> * Marco Schmidt [2014-07-31 13:42]: > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2014-04, > "Relaxing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. I support this draft! 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 sghasemi at ripe.net Thu Aug 7 15:46:01 2014 From: sghasemi at ripe.net (Saloumeh Ghasemi) Date: Thu, 07 Aug 2014 15:46:01 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-01, "Abandoning the Minimum Allocation Size for IPv4" Message-ID: <53E38319.9070800@ripe.net> Dear colleagues, We are pleased to announce that the accepted RIPE Policy Proposal 2014-01, "Abandoning the Minimum Allocation Size for IPv4", has now been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2014-01 The new RIPE Document, ripe-622, "IPv4 Address Allocation and Assignment Policy", is available at: https://www.ripe.net/ripe/docs/ripe-622/ Please note that we republished the RIPE Document, "IPv4 Address Allocation and Assignment Policy", because it was originally published with a small error. The new, correct document is ripe-622, which deprecates ripe-621. As per section 5.5 of this new RIPE Document, Local Internet Registries (LIRs) are now allowed to transfer allocated Provider Aggregatable (PA) address space to other LIRs, regardless of the size of the allocations: https://www.ripe.net/ripe/docs/ripe-622#55 The RIPE NCC will continue to issue /22 allocations, as per section 5.1: https://www.ripe.net/ripe/docs/ripe-622#51 If you have any questions, please contact >. Regards, Saloumeh Ghasemi Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ula at ripn.net Fri Aug 8 13:10:27 2014 From: ula at ripn.net (Larisa Yurkina) Date: Fri, 08 Aug 2014 15:10:27 +0400 Subject: [address-policy-wg] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer) In-Reply-To: <20140804123021.GC29660@hydra.ck.polsl.pl> References: <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> <20140804123021.GC29660@hydra.ck.polsl.pl> Message-ID: <53E4B01F.2070206@ripn.net> Piotr Strzyzewski wrote, 04.08.2014 16:30: I also support this prposal. With respect, Larisa Yurkina RosNIIROS > On Mon, Jul 28, 2014 at 08:18:53PM +0200, Gert Doering wrote: >> Dear AP WG, >> >> On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: >>> The draft document for the proposal described in 2014-02, >>> "Allow IPv4 PI transfer" 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/2014-02 >>> >>> and the draft document at: >>> >>> https://www.ripe.net/ripe/policies/proposals/2014-02/draft >> >> We could use a bit more input on this proposal. We have one clear >> statement of support, and one mail that puts up some questions while not >> taking a clear pro/con position - and that is not enough to declare >> anything except "needs more time" at the end of review phase. >> >> So, tell me your thoughts, please. > I support this proposal. > > Piotr > From hamed at skydsl.ir Sat Aug 9 07:37:00 2014 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Sat, 9 Aug 2014 10:07:00 +0430 Subject: [address-policy-wg] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer) In-Reply-To: <20140728181853.GA48371@Space.Net> References: <20140710100351.9B9FF60276@mobil.space.net> <20140728181853.GA48371@Space.Net> Message-ID: Hi all I support Regards On Mon, Jul 28, 2014 at 10:48 PM, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > > The draft document for the proposal described in 2014-02, > > "Allow IPv4 PI transfer" 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/2014-02 > > > > and the draft document at: > > > > https://www.ripe.net/ripe/policies/proposals/2014-02/draft > > > We could use a bit more input on this proposal. We have one clear > statement of support, and one mail that puts up some questions while not > taking a clear pro/con position - and that is not enough to declare > anything except "needs more time" at the end of review phase. > > So, tell me your thoughts, please. > > thanks, > > Gert Doering, > APWG chair > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -- -------------------------------------------- I Hamed Shafaghi I I Managing Director I I Skydsl? Telecom I hamed at skydsl.ir I www.skydsl.ir I -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Mon Aug 11 17:04:30 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 11 Aug 2014 19:04:30 +0400 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 Message-ID: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> Dear Sirs, I suggest to allow transfer from the last /8 only in 2 years after date of allocation from RIPE NCC. I see in the transfer list that this is already common practice to transfer /22 from the last /8. Any Pros/cons? -- Aleksei Ivanov LeaderTelecom -- ??? ?????? ?????????? [Ticket#-] ? ???? ??????. --- ? ?????????, ?????????????? ? ??????????? ???????? ??? "????????????" ? ???.: 8(495)778-98-51 [1]www.LeaderTelecom.ru ? URL: [2]http://www.InstantSSL.su/ - SSL-??????????? Comodo URL: [3]http://Symantec.Leadertelecom.ru/?- SSL-??????????? Symantec (Verisign) URL: [4]http://www.Thawte.su/?- SSL-??????????? Thawte URL: [5]http://www.HostingConsult.ru/ - ???????? ?????, IP-?????? ? AS [1] http://www.leadertelecom.ru [2] http://www.instantssl.su/ [3] http://symantec.leadertelecom.ru [4] http://www.thawte.su/ [5] http://www.hostingconsult.ru/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Mon Aug 11 17:27:58 2014 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 11 Aug 2014 17:27:58 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> References: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> Message-ID: <1944240588.20140811172758@devnull.ru> Aleksei, what is the point of your proposal? -- Sergey Monday, August 11, 2014, 5:04:30 PM, you wrote: LL> Dear Sirs, LL> I suggest to allow transfer from the last /8 only in 2 years after date of LL> allocation from RIPE NCC. I see in the transfer list that this is already LL> common practice to transfer /22 from the last /8. LL> Any Pros/cons? LL> -- LL> Aleksei Ivanov LL> LeaderTelecom From ak at list.ak.cx Mon Aug 11 17:41:23 2014 From: ak at list.ak.cx (Andre Keller) Date: Mon, 11 Aug 2014 17:41:23 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> References: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> Message-ID: <53E8E423.5070204@list.ak.cx> Hi Aleksei, On 11.08.2014 17:04, LeaderTelecom Ltd. wrote: > I suggest to allow transfer from the last /8 only in 2 years after date of > allocation from RIPE NCC. I see in the transfer list that this is already > common practice to transfer /22 from the last /8. I have sympathy for this request, as I do think it is wrong to apply for an IPv4 block from the last /8 if you simply do not need it and just want to generate some additional income. But, I'm afraid the market will do these transfers anyway. And if these transfers happen I'd rather have them supervised and tracked by RIPE. Regards Andr? From info at leadertelecom.ru Mon Aug 11 18:09:18 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 11 Aug 2014 20:09:18 +0400 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1944240588.20140811172758@devnull.ru> References: <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> Message-ID: <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> Sergey, >?what is the point of your proposal? I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool.? Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. ? -- Aleksei ? LL> Dear Sirs, LL> I suggest to allow transfer from the last /8 only in 2 years after date of LL> allocation from RIPE NCC. I see in the transfer list that this is already LL> common practice to transfer /22 from the last /8. LL> Any Pros/cons? LL> -- LL> Aleksei Ivanov LL> LeaderTelecom -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at leadertelecom.ru Mon Aug 11 18:15:22 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 11 Aug 2014 20:15:22 +0400 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <53E8E423.5070204@list.ak.cx> References: <53E8E423.5070204@list.ak.cx> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> Message-ID: <1407773721.562588.126169611.547246.2@otrs.hostingconsult.ru> Dear Andr?, > But, I'm afraid the market will do these transfers anyway. And if >?these?transfers happen I'd rather have them supervised and tracked by RIPE. 1. RIPE will get request for transfer. 2. If IPv4 block is from last /8, then check date of allocation for this LIR. 3. If date_of_allocation + 2 years < date_now then allow transfer; else - reject. It is very simple.? ? -- Aleksei Ivanov 11.08.2014 19:43 - Andre Keller ???????(?): Hi Aleksei, On 11.08.2014 17:04, LeaderTelecom Ltd. wrote: > I suggest to allow transfer from the last /8 only in 2 years after date of > allocation from RIPE NCC. I see in the transfer list that this is already > common practice to transfer /22 from the last /8. I have sympathy for this request, as I do think it is wrong to apply for an IPv4 block from the last /8 if you simply do not need it and just want to generate some additional income. But, I'm afraid the market will do these transfers anyway. And if these transfers happen I'd rather have them supervised and tracked by RIPE. Regards Andr? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at list.ak.cx Mon Aug 11 18:27:23 2014 From: ak at list.ak.cx (Andre Keller) Date: Mon, 11 Aug 2014 18:27:23 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407773721.562588.126169611.547246.2@otrs.hostingconsult.ru> References: <53E8E423.5070204@list.ak.cx> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773721.562588.126169611.547246.2@otrs.hostingconsult.ru> Message-ID: <53E8EEEB.8090504@list.ak.cx> Hi Aleksei, On 11.08.2014 18:15, LeaderTelecom Ltd. wrote: > > 1. RIPE will get request for transfer. 2. If IPv4 block is from last /8, > then check date of allocation for this LIR. > 3. If date_of_allocation + 2 years < date_now then allow transfer; else - > reject. > > It is very simple. well the problem is, that when potential transfer parties know that RIPE will reject a request, they wont present it to RIPE but do some contracts on their own. But they certainly will not refrain from the transfer if they need the addresses. This leads to inaccurate data in the RIPE database. Regards Andr? From sergey at devnull.ru Mon Aug 11 19:57:58 2014 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 11 Aug 2014 19:57:58 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> References: <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> Message-ID: <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> Aleksei, I am able to read the written text :) but I don?t see the reason for your proposal. Do you consider unfair single (at least in first 2 years) allocation transfer? Why? Or maybe you would like to limit the practice when companies being created for requesting allocation only? -- Sergey On 11 Aug 2014, at 18:09, LeaderTelecom Ltd. wrote: > Sergey, > > > what is the point of your proposal? > I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool. > > Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. > > -- > Aleksei > > LL> Dear Sirs, > > LL> I suggest to allow transfer from the last /8 only in 2 years after date of > LL> allocation from RIPE NCC. I see in the transfer list that this is already > LL> common practice to transfer /22 from the last /8. > LL> Any Pros/cons? > > LL> -- > LL> Aleksei Ivanov > LL> LeaderTelecom > > > From info at leadertelecom.ru Mon Aug 11 21:49:33 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Mon, 11 Aug 2014 23:49:33 +0400 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> References: <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> Message-ID: <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> Dear Sergey, >?I am able to read the written text :) but I don?t see the reason for your proposal. Ok. I thinked that I wrote not very clear. > Or maybe you would like to limit the practice when companies being created for requesting?allocation only? Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. If the last /8 starts from digth "185" then we can see thansfers from companies: 23.01.2013?"TOP NET" PJSC 15.05.2013?CallWithMe 01.07.2013?VERIXI SPRL 04.07.2013?PJSC "Fars Telecommunication Company" 09.07.2013?Aria Web Development LLC 16.10.2013?Pars Fonoun Ofogh Information Technology and Communications Company LTD 17.12.2013?Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 02.01.2014?Sara Rebollido Sueiro 24.01.2014?NOV'IT SAS 27.01.2014?Flex Networks Services B.V. 27.01.2014?IPhouse B.V. 27.01.2014?NLTM B.V. 04.02.2014?Dark Group Ltd 04.02.2014?Froehlich-Reisen GmbH 05.02.2014?Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014?Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014?Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014?Skylogic Polska Sp. Z.o.o. 28.02.2014?Netfactor Iletisim Hizmetleri Limited Sirketi 13.03.2014?LLC Arksys 21.03.2014?Xite Group BV 25.03.2014?ANDRZEJ BACINSKI trading as PUMPS & SYSTEMS 10.04.2014?LEVEL IP ITALIA S.R.L. 29.04.2014?STIS Engineering co. LTD 06.05.2014?Santrex Internet Services Ltd. 08.05.2014?AnDilo AB 13.05.2014?GLASHELDER BV 15.05.2014?Reseau Stella SARL 16.05.2014?Connect-it Telecom BV 16.05.2014?Mobile Communications (MOCO) BV 02.06.2014?A.M. Bayhan is trading as "DediColo Services" 02.06.2014?DediColo B.V. 04.06.2014?CLOUDGLOBAL FRANCE SAS 06.06.2014?Optimal IT Development SRL 20.06.2014?BIKS+ Ltd 20.06.2014?CJSC ADVANTAGE TELECOM 26.06.2014?International Communication company Persian Sheetsan Ltd. 10.07.2014?TELECABLE LTD 23.07.2014?"StoTelecom" Ltd. 23.07.2014?Michiel Muhlenbaumer 29.07.2014?EMY AUTO BEST SRL 30.07.2014?Host Sailor Ltd. 31.07.2014?Van Veen Beheer BV 04.08.2014?WBS Consulting Czech Republic s.r.o. ? ? -- Aleksei 11.08.2014 21:58 - Sergey Myasoedov ???????(?): Aleksei, I am able to read the written text :) but I don?t see the reason for your proposal. Do you consider unfair single (at least in first 2 years) allocation transfer? Why? Or maybe you would like to limit the practice when companies being created for requesting allocation only? -- Sergey On 11 Aug 2014, at 18:09, LeaderTelecom Ltd. wrote: > Sergey, > > > what is the point of your proposal? > I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool. > > Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. >?? > -- > Aleksei >?? > LL> Dear Sirs, > > LL> I suggest to allow transfer from the last /8 only in 2 years after date of > LL> allocation from RIPE NCC. I see in the transfer list that this is already > LL> common practice to transfer /22 from the last /8. > LL> Any Pros/cons? > > LL> -- > LL> Aleksei Ivanov > LL> LeaderTelecom > > >?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey at devnull.ru Tue Aug 12 01:22:33 2014 From: sergey at devnull.ru (Sergey Myasoedov) Date: Tue, 12 Aug 2014 01:22:33 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> References: <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> Message-ID: <3E09530A-6FDF-4E8F-97B0-CE692D026E23@devnull.ru> > Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. I see. You mentioned 37 transfers in 2014, that equal to /17,/20,/22. Is this number significant enough to develop the policy change? -- Sergey On 11 Aug 2014, at 21:49, LeaderTelecom Ltd. wrote: > Dear Sergey, > > > I am able to read the written text :) but I don?t see the reason for your proposal. > Ok. I thinked that I wrote not very clear. > > > Or maybe you would like to limit the practice when companies being created for requesting allocation only? > > Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. > > If the last /8 starts from digth "185" then we can see thansfers from companies: > 23.01.2013 "TOP NET" PJSC > 15.05.2013 CallWithMe > 01.07.2013 VERIXI SPRL > 04.07.2013 PJSC "Fars Telecommunication Company" > 09.07.2013 Aria Web Development LLC > 16.10.2013 Pars Fonoun Ofogh Information Technology and Communications Company LTD > 17.12.2013 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 02.01.2014 Sara Rebollido Sueiro > 24.01.2014 NOV'IT SAS > 27.01.2014 Flex Networks Services B.V. > 27.01.2014 IPhouse B.V. > 27.01.2014 NLTM B.V. > 04.02.2014 Dark Group Ltd > 04.02.2014 Froehlich-Reisen GmbH > 05.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Skylogic Polska Sp. Z.o.o. > 28.02.2014 Netfactor Iletisim Hizmetleri Limited Sirketi > 13.03.2014 LLC Arksys > 21.03.2014 Xite Group BV > 25.03.2014 ANDRZEJ BACINSKI trading as PUMPS & SYSTEMS > 10.04.2014 LEVEL IP ITALIA S.R.L. > 29.04.2014 STIS Engineering co. LTD > 06.05.2014 Santrex Internet Services Ltd. > 08.05.2014 AnDilo AB > 13.05.2014 GLASHELDER BV > 15.05.2014 Reseau Stella SARL > 16.05.2014 Connect-it Telecom BV > 16.05.2014 Mobile Communications (MOCO) BV > 02.06.2014 A.M. Bayhan is trading as "DediColo Services" > 02.06.2014 DediColo B.V. > 04.06.2014 CLOUDGLOBAL FRANCE SAS > 06.06.2014 Optimal IT Development SRL > 20.06.2014 BIKS+ Ltd > 20.06.2014 CJSC ADVANTAGE TELECOM > 26.06.2014 International Communication company Persian Sheetsan Ltd. > 10.07.2014 TELECABLE LTD > 23.07.2014 "StoTelecom" Ltd. > 23.07.2014 Michiel Muhlenbaumer > 29.07.2014 EMY AUTO BEST SRL > 30.07.2014 Host Sailor Ltd. > 31.07.2014 Van Veen Beheer BV > 04.08.2014 WBS Consulting Czech Republic s.r.o. > > > -- > Aleksei > > 11.08.2014 21:58 - Sergey Myasoedov ???????(?): > Aleksei, > I am able to read the written text :) but I don?t see the reason for your > proposal. > > Do you consider unfair single (at least in first 2 years) allocation transfer? > Why? > > Or maybe you would like to limit the practice when companies being created for > requesting allocation only? > > > -- > Sergey > > On 11 Aug 2014, at 18:09, LeaderTelecom Ltd. wrote: > > > Sergey, > > > > > what is the point of your proposal? > > I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool. > > > > Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. > > > > -- > > Aleksei > > > > LL> Dear Sirs, > > > > LL> I suggest to allow transfer from the last /8 only in 2 years after date of > > LL> allocation from RIPE NCC. I see in the transfer list that this is already > > LL> common practice to transfer /22 from the last /8. > > LL> Any Pros/cons? > > > > LL> -- > > LL> Aleksei Ivanov > > LL> LeaderTelecom > > > > > > > > From info at leadertelecom.ru Tue Aug 12 09:02:02 2014 From: info at leadertelecom.ru (LeaderTelecom Ltd.) Date: Tue, 12 Aug 2014 11:02:02 +0400 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <3E09530A-6FDF-4E8F-97B0-CE692D026E23@devnull.ru> References: <3E09530A-6FDF-4E8F-97B0-CE692D026E23@devnull.ru> <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> Message-ID: <1407826921.789037.500606564.547246.2@otrs.hostingconsult.ru> Sergey, >?I see. You mentioned 37 transfers in 2014, that equal to /17,/20,/22. >?Is this number?significant enough to develop the policy change? I think, yes. While amont of such transfers from last /8 will increase anyway. Sergey, what is your opinion? -- Aleksei 12.08.2014 03:23 - Sergey Myasoedov ???????(?): > Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. I see. You mentioned 37 transfers in 2014, that equal to /17,/20,/22. Is this number significant enough to develop the policy change? -- Sergey On 11 Aug 2014, at 21:49, LeaderTelecom Ltd. wrote: > Dear Sergey, > > > I am able to read the written text :) but I don?t see the reason for your proposal. > Ok. I thinked that I wrote not very clear. > > > Or maybe you would like to limit the practice when companies being created for requesting allocation only? > > Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. > > If the last /8 starts from digth "185" then we can see thansfers from companies: > 23.01.2013 "TOP NET" PJSC > 15.05.2013 CallWithMe > 01.07.2013 VERIXI SPRL > 04.07.2013 PJSC "Fars Telecommunication Company" > 09.07.2013 Aria Web Development LLC > 16.10.2013 Pars Fonoun Ofogh Information Technology and Communications Company LTD > 17.12.2013 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 02.01.2014 Sara Rebollido Sueiro > 24.01.2014 NOV'IT SAS > 27.01.2014 Flex Networks Services B.V. > 27.01.2014 IPhouse B.V. > 27.01.2014 NLTM B.V. > 04.02.2014 Dark Group Ltd > 04.02.2014 Froehlich-Reisen GmbH > 05.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" > 13.02.2014 Skylogic Polska Sp. Z.o.o. > 28.02.2014 Netfactor Iletisim Hizmetleri Limited Sirketi > 13.03.2014 LLC Arksys > 21.03.2014 Xite Group BV > 25.03.2014 ANDRZEJ BACINSKI trading as PUMPS & SYSTEMS > 10.04.2014 LEVEL IP ITALIA S.R.L. > 29.04.2014 STIS Engineering co. LTD > 06.05.2014 Santrex Internet Services Ltd. > 08.05.2014 AnDilo AB > 13.05.2014 GLASHELDER BV > 15.05.2014 Reseau Stella SARL > 16.05.2014 Connect-it Telecom BV > 16.05.2014 Mobile Communications (MOCO) BV > 02.06.2014 A.M. Bayhan is trading as "DediColo Services" > 02.06.2014 DediColo B.V. > 04.06.2014 CLOUDGLOBAL FRANCE SAS > 06.06.2014 Optimal IT Development SRL > 20.06.2014 BIKS+ Ltd > 20.06.2014 CJSC ADVANTAGE TELECOM > 26.06.2014 International Communication company Persian Sheetsan Ltd. > 10.07.2014 TELECABLE LTD > 23.07.2014 "StoTelecom" Ltd. > 23.07.2014 Michiel Muhlenbaumer > 29.07.2014 EMY AUTO BEST SRL > 30.07.2014 Host Sailor Ltd. > 31.07.2014 Van Veen Beheer BV > 04.08.2014 WBS Consulting Czech Republic s.r.o. >?? >?? > -- > Aleksei > > 11.08.2014 21:58 - Sergey Myasoedov ???????(?): > Aleksei, > I am able to read the written text :) but I don?t see the reason for your > proposal. > > Do you consider unfair single (at least in first 2 years) allocation transfer? > Why? > > Or maybe you would like to limit the practice when companies being created for > requesting allocation only? > > > -- > Sergey > > On 11 Aug 2014, at 18:09, LeaderTelecom Ltd. wrote: > > > Sergey, > > > > > what is the point of your proposal? > > I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool. > > > > Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. > >?? > > -- > > Aleksei > >?? > > LL> Dear Sirs, > > > > LL> I suggest to allow transfer from the last /8 only in 2 years after date of > > LL> allocation from RIPE NCC. I see in the transfer list that this is already > > LL> common practice to transfer /22 from the last /8. > > LL> Any Pros/cons? > > > > LL> -- > > LL> Aleksei Ivanov > > LL> LeaderTelecom > > > > > >?? > >?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Tue Aug 12 10:06:21 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 12 Aug 2014 10:06:21 +0200 Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> References: <8AAB5159-021E-47D6-B5A2-62C1313472CD@devnull.ru> <1944240588.20140811172758@devnull.ru> <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <1407773357.338313.597782778.547246.2@otrs.hostingconsult.ru> <1407786572.652326.549308473.547246.2@otrs.hostingconsult.ru> Message-ID: <002a01cfb604$518c5730$f4a50590$@a2b-internet.com> Hi Aleksei, Seeing some of the LIR?s I?ve done some work for, I can guarantee that not all transfers that are in the list are being transferred to sell outside their corporate structure. I?ve asked on this same list about 1.5 years ago, if it was required to close the option to merge LIR?s which already have their final /8 /22 or not allow the option for transfers from a final /8 /22 to an LIR which already received their final /8 /22.. It wasn?t required was the reply, so I didn?t created the policy to plug it. Currently I don?t see that plugging this will benefit the accuracy of the registry, so for me, I would not support this. To give an indication, not allowing a transfer from a new LIR will not fix the practice or what you try to accomplish ... Either you still have the transfers, but they are not registered .. OR they find other ways to do it, which are not listed on the transfer listing page. Regards, Erik Bais Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens LeaderTelecom Ltd. Verzonden: maandag 11 augustus 2014 21:50 Aan: sergey at devnull.ru CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 Dear Sergey, > I am able to read the written text :) but I don?t see the reason for your proposal. Ok. I thinked that I wrote not very clear. > Or maybe you would like to limit the practice when companies being created for requesting allocation only? Yes. I afaraid that last /8 will be used for creating new LIRs only reselling IPv4-adresses. As a result last /8 will be run out very fast. If the last /8 starts from digth "185" then we can see thansfers from companies: 23.01.2013 "TOP NET" PJSC 15.05.2013 CallWithMe 01.07.2013 VERIXI SPRL 04.07.2013 PJSC "Fars Telecommunication Company" 09.07.2013 Aria Web Development LLC 16.10.2013 Pars Fonoun Ofogh Information Technology and Communications Company LTD 17.12.2013 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 02.01.2014 Sara Rebollido Sueiro 24.01.2014 NOV'IT SAS 27.01.2014 Flex Networks Services B.V. 27.01.2014 IPhouse B.V. 27.01.2014 NLTM B.V. 04.02.2014 Dark Group Ltd 04.02.2014 Froehlich-Reisen GmbH 05.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014 Julian Alberto Gomez Hernandez trading as "Adjenet Networks" 13.02.2014 Skylogic Polska Sp. Z.o.o. 28.02.2014 Netfactor Iletisim Hizmetleri Limited Sirketi 13.03.2014 LLC Arksys 21.03.2014 Xite Group BV 25.03.2014 ANDRZEJ BACINSKI trading as PUMPS & SYSTEMS 10.04.2014 LEVEL IP ITALIA S.R.L. 29.04.2014 STIS Engineering co. LTD 06.05.2014 Santrex Internet Services Ltd. 08.05.2014 AnDilo AB 13.05.2014 GLASHELDER BV 15.05.2014 Reseau Stella SARL 16.05.2014 Connect-it Telecom BV 16.05.2014 Mobile Communications (MOCO) BV 02.06.2014 A.M. Bayhan is trading as "DediColo Services" 02.06.2014 DediColo B.V. 04.06.2014 CLOUDGLOBAL FRANCE SAS 06.06.2014 Optimal IT Development SRL 20.06.2014 BIKS+ Ltd 20.06.2014 CJSC ADVANTAGE TELECOM 26.06.2014 International Communication company Persian Sheetsan Ltd. 10.07.2014 TELECABLE LTD 23.07.2014 "StoTelecom" Ltd. 23.07.2014 Michiel Muhlenbaumer 29.07.2014 EMY AUTO BEST SRL 30.07.2014 Host Sailor Ltd. 31.07.2014 Van Veen Beheer BV 04.08.2014 WBS Consulting Czech Republic s.r.o. -- Aleksei 11.08.2014 21:58 - Sergey Myasoedov ???????(?): Aleksei, I am able to read the written text :) but I don?t see the reason for your proposal. Do you consider unfair single (at least in first 2 years) allocation transfer? Why? Or maybe you would like to limit the practice when companies being created for requesting allocation only? -- Sergey On 11 Aug 2014, at 18:09, LeaderTelecom Ltd. > wrote: > Sergey, > > > what is the point of your proposal? > I propose don't allow transfers from last /8 during first 2 years afer date of allocation from RIPE NCC pool. > > Example: some LIR get IPv4 from last /8 at 11.08.2014. In period 11.08.2014 - 10.08.2016 transfer of it's IPs are not allowed. Since 11.08.2016 this LIR can transfer IPv4 to any LIR. > > -- > Aleksei > > LL> Dear Sirs, > > LL> I suggest to allow transfer from the last /8 only in 2 years after date of > LL> allocation from RIPE NCC. I see in the transfer list that this is already > LL> common practice to transfer /22 from the last /8. > LL> Any Pros/cons? > > LL> -- > LL> Aleksei Ivanov > LL> LeaderTelecom > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Tue Aug 12 10:15:21 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 12 Aug 2014 10:15:21 +0200 (CEST) Subject: [address-policy-wg] [Ticket#2014081101013263] Transfer from last /8 In-Reply-To: <53E8E423.5070204@list.ak.cx> References: <1407769470.650955.395885159.547246.2@otrs.hostingconsult.ru> <53E8E423.5070204@list.ak.cx> Message-ID: On Mon, 11 Aug 2014, Andre Keller wrote: > But, I'm afraid the market will do these transfers anyway. And if these > transfers happen I'd rather have them supervised and tracked by RIPE. I agree completely. Introducing a policy like this is just hand-waving, it's not enforcable. Also, can we please stop trying to squeeze blood and fairness out of the IPv4 stone? We know it's not fair, but as far as I can tell, nothing has changed the past 3-5 years so let's just leave the policy as-is. I want for RIPE to keep the database correct and to have as little other work and administration as possible with IPv4. The only way to make more IPv4 addresses available on the market to the people who need them is to create a working transfer market with money involved. Yes, this is unfair but so is the fact that I currently live in an apartment that cost 0.3% of current market value to buy in 1961 when it was originally built. Let's make sure we have a liquid IPv4 address market so people who need addresses short term can get them directly from others without creating huge hassles which only means specialists (brokers) can profit from it. -- Mikael Abrahamsson email: swmike at swm.pp.se From ripe-ml-2012 at ssd.axu.tm Thu Aug 14 05:02:20 2014 From: ripe-ml-2012 at ssd.axu.tm (Aleksi Suhonen) Date: Thu, 14 Aug 2014 06:02:20 +0300 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140711082317.B6B9156DC@mail.axu.tm> References: <20140711082317.B6B9156DC@mail.axu.tm> Message-ID: <53EC26BC.2040506@ssd.axu.tm> Hello, On 07/11/2014 11:21 AM, Marco Schmidt wrote: > The draft document for the proposal described in 2014-03, > "Remove Multihoming Requirement for AS Number Assignments" has been > published. The impact analysis that was conducted for this proposal > has also been published. I know I'm late in the game, but I thought I'd contribute this view rather than stay silent: Remove multi homing requirement for 32bit ASNs only, keep the requirement for 16bit ASNs. I foresee new weird legacy setups run by non-ISPs that still require a unique ASN well into the future. The example I would usually use is factory floor environments, but that is probably not an applicable example here. I hope someone else's imagination can supply a valid example. Cheers, -- Aleksi Suhonen You say "potato", I say "closest-exit." From job at instituut.net Sat Aug 16 13:31:24 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 13:31:24 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <53EC26BC.2040506@ssd.axu.tm> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> Message-ID: <20140816113124.GA50101@pc154.home> Dear all, Based on the feedback from the working group we have developed a new iteration of the proposal. Concerns addressed: - remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex le Heux, offlist; Erik Bais, offlist) - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B "Autonomous System Number (ASN) Consumption") - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014 What has not been addressed is the creation of an exhaustive list of acceptable reasons to request an ASN. The authors do not know how to update (without full PDP process) the list when new technologies or methodologies arise. Rather, the authors believe that RIPE NCC is responsible for maintaining an accurate registry than evaluate network designs. In a years time the RIPE NCC could publish an aggregated report on the recorded needs, possibly to inspire the community to reconsider this policy. ----------------- replaces section 2.0 from RIPE-525 ----------------- 2.0 Assignment Criteria A new AS Number should only be assigned when the End User expresses a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. When requesting a 16 bit AS Number, the network must be multihomed using the assigned AS Number within 6 months. A 32 bit AS Number is exempt from the multihoming requirement. When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document ?Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region?. ------------------------------------------------------------------------ Kind regards, Job & Ytti From nick at inex.ie Sat Aug 16 14:09:40 2014 From: nick at inex.ie (Nick Hilliard) Date: Sat, 16 Aug 2014 13:09:40 +0100 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816113124.GA50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> Message-ID: <53EF4A04.7060002@inex.ie> On 16/08/2014 12:31, Job Snijders wrote: > A new AS Number should only be assigned when the End User expresses a need > that cannot be satisfied with an existing AS Number. RIPE NCC will record, > but not evaluate this need. This is an excellent idea. I have a legitimate operational need for a large number of autonomous system numbers - slightly less than 2^32. The rest of the internet will be left with a couple of thousand which should do for the rest of time, assuming that they're handled sparingly. Anyways, people can use the private assignment range if they're stuck. The RIPE NCC can record my need and keep it confidential. So count this as definite support for the proposal as it stands. Nick From job at instituut.net Sat Aug 16 14:22:29 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 14:22:29 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <53EF4A04.7060002@inex.ie> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> Message-ID: <20140816122229.GB50101@pc154.home> On Sat, Aug 16, 2014 at 01:09:40PM +0100, Nick Hilliard wrote: > On 16/08/2014 12:31, Job Snijders wrote: > > A new AS Number should only be assigned when the End User expresses a need > > that cannot be satisfied with an existing AS Number. RIPE NCC will record, > > but not evaluate this need. > > This is an excellent idea. I have a legitimate operational need for a > large number of autonomous system numbers - slightly less than 2^32. The > rest of the internet will be left with a couple of thousand which should do > for the rest of time, assuming that they're handled sparingly. Anyways, > people can use the private assignment range if they're stuck. Already today you can request slightly less than 2^32 ASNs. For each request indicate that the requested ASN will peer with the two ASNs requested previously. > So count this as definite support for the proposal as it stands. Thank you for your support. Kind regards, Job From gert at space.net Sat Aug 16 14:58:14 2014 From: gert at space.net (Gert Doering) Date: Sat, 16 Aug 2014 14:58:14 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <53EF4A04.7060002@inex.ie> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> Message-ID: <20140816125814.GY51793@Space.Net> Hi, On Sat, Aug 16, 2014 at 01:09:40PM +0100, Nick Hilliard wrote: > So count this as definite support for the proposal as it stands. Uh. I find it slightly hard to judge whether this was sarcastic or whether you are actually indeed supporting the proposal...? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From saku at ytti.fi Sat Aug 16 15:33:57 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 16 Aug 2014 16:33:57 +0300 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816122229.GB50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> Message-ID: On 16 August 2014 15:22, Job Snijders wrote: > Already today you can request slightly less than 2^32 ASNs. For each > request indicate that the requested ASN will peer with the two ASNs > requested previously. ACK. And if there seem to be worrying request rate, situation is unchanged, we need to address that, with today's policy and with tomorrow's policy. I personally would want to see YRC implemented, 1EUR/year/resource, 4294967296 EUR annual revenue will make it possible to finance sufficient long AS number for Nick's use cases. -- ++ytti From nick at inex.ie Sat Aug 16 15:41:37 2014 From: nick at inex.ie (Nick Hilliard) Date: Sat, 16 Aug 2014 14:41:37 +0100 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816125814.GY51793@Space.Net> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816125814.GY51793@Space.Net> Message-ID: <53EF5F91.4090403@inex.ie> On 16/08/2014 13:58, Gert Doering wrote: > Uh. I find it slightly hard to judge whether this was sarcastic or > whether you are actually indeed supporting the proposal...? you can probably tell I was joking. I don't support proposals when there are no basic mechanisms in place to stop people from abusing them. Previously, this could have been enforced by the ?50 fee per annum for each ASN, but this fee disappeared in the 2013 RIPE NCC charging scheme on recommendation from the RIPE NCC Charging Scheme Task Force: > http://www.ripe.net/lir-services/ncc/gm/april-2012/supporting-documents/report-of-the-charging-scheme-task-force > http://www.ripe.net/lir-services/ncc/gm/april-2012/presentations/report-of-the-charging-scheme-task-force/view The task force reported this: "The task force thought that charging for ASNs was unnecessary. Members who have ASNs also have address space so they will still be charged." The Task Force did not take into account that charging for resources also acts as a simple but effective abuse-dampening mechanism, which was one of the original reasons that charging for PI resources went into the contractual requirements policy (the other main reason was that charging for resources acts as a simple garbage collection mechanism, which we have also lost). I had planned to object to this at the 2012 RIPE NCC GM but unfortunately wasn't able to attend the meeting. If this policy is passed as-is, then anyone will be able to abuse the policy to request an arbitrary number of ASNs for any reason, and the RIPE NCC will not be able to refuse the request. This is a particular problem given that we have a shortage of ASN16s and a feature disparity between ASN16s and ASN32s. I have no major problem problem handing out ASNs on request but if we do, there needs to be a damper mechanism in place to stop abuse. To do this, either APWG should put in place a policy for the RIPE NCC to evaluate ASN requests and assign according to need, or else it should charge for ASN assignments. I strongly favour the latter, as it is simpler and less ambiguous. It also restores the garbage collection mechanism which we previously had and have now lost. Nick From ebais at a2b-internet.com Sat Aug 16 15:49:37 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Aug 2014 15:49:37 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816113124.GA50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> Message-ID: Hi Job, As stated to you offlist, I support the idea of the proposal, but I can't disagree with the NCC review of how the current proposal is written. I think a lot of the discussion can be removed by changing the word MUST into a SHOULD in section 2.0 of ripe-525 Personally I don't think the NCC should go further into asking if a requestor has considered the use of a private AS, but shouldn't enforce or question the motives of someone not to want to use a private AS. I can imagine that there are operational use cases for requesting a unique ASn without someone going full multi-homing at implementation. I rather have someone register for a AS instead of picking some random number which might lead to other issues globally or lie tot the NCC in order to obtain one. I trust the NCC to monitor abuse of the intended policy on actual impact, which will allow more than sufficient time to change the charging scheme if needed in the future to bite guys like Nick in the ..... ;-) Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 16 aug. 2014 om 13:31 heeft Job Snijders het volgende geschreven: > > Dear all, > > Based on the feedback from the working group we have developed a > new iteration of the proposal. > > Concerns addressed: > > - remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex > le Heux, offlist; Erik Bais, offlist) > - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; > Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B > "Autonomous System Number (ASN) Consumption") > - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014 > > What has not been addressed is the creation of an exhaustive list of > acceptable reasons to request an ASN. The authors do not know how to > update (without full PDP process) the list when new technologies or > methodologies arise. Rather, the authors believe that RIPE NCC is > responsible for maintaining an accurate registry than evaluate network > designs. In a years time the RIPE NCC could publish an aggregated report > on the recorded needs, possibly to inspire the community to reconsider > this policy. > > ----------------- replaces section 2.0 from RIPE-525 ----------------- > 2.0 Assignment Criteria > > A new AS Number should only be assigned when the End User expresses a need > that cannot be satisfied with an existing AS Number. RIPE NCC will record, > but not evaluate this need. > > When requesting a 16 bit AS Number, the network must be multihomed using > the assigned AS Number within 6 months. A 32 bit AS Number is exempt from > the multihoming requirement. > > When requesting an AS Number, the routing policy of the Autonomous System > must be provided. The new unique routing policy should be defined in RPSL > language, as used in the RIPE Database. > > The RIPE NCC will assign the AS Number directly to the End User upon a > request properly submitted to the RIPE NCC either directly or through a > sponsoring LIR. AS Number assignments are subject to the policies described > in the RIPE Document ?Contractual Requirements for Provider Independent > Resource Holders in the RIPE NCC Service Region?. > ------------------------------------------------------------------------ > > Kind regards, > > Job & Ytti > From gert at space.net Sat Aug 16 15:50:56 2014 From: gert at space.net (Gert Doering) Date: Sat, 16 Aug 2014 15:50:56 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> Message-ID: <20140816135056.GZ51793@Space.Net> Hi, On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote: > I personally would want to see YRC implemented, 1EUR/year/resource, > 4294967296 EUR annual revenue will make it possible to finance > sufficient long AS number for Nick's use cases. Unfortunately, APWG has no formal say in this, as everything related to money is for the members to decide, and it seems sufficient LIRs wanted "no extra costs for AS numbers!" to lobby for the removal from the charging scheme... (we had "50 EUR per AS/year" in it) One would need to personally propose this to the board so they can include it in the new charging scheme drafts, *and* get enough members to actually vote for it... Gert Doering -- no particular hats -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From job at instituut.net Sat Aug 16 16:34:19 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 16:34:19 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816135056.GZ51793@Space.Net> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> Message-ID: <20140816143419.GD50101@pc154.home> On Sat, Aug 16, 2014 at 03:50:56PM +0200, Gert Doering wrote: > On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote: > > I personally would want to see YRC implemented, 1EUR/year/resource, > > 4294967296 EUR annual revenue will make it possible to finance > > sufficient long AS number for Nick's use cases. > > Unfortunately, APWG has no formal say in this, as everything related > to money is for the members to decide, and it seems sufficient LIRs > wanted "no extra costs for AS numbers!" to lobby for the removal > from the charging scheme... (we had "50 EUR per AS/year" in it) > > One would need to personally propose this to the board so they can include > it in the new charging scheme drafts, *and* get enough members to actually > vote for it... As author I wholeheartedly agree with the two main concerns Nick raises, we described this concern in the Rationale section B. Going forward I see two possible paths, and would appreciate feedback on either. 1) We add a clause to the policy that the policy only takes effect if either in 2014 or 2015, a yearly recurring cost is associated with AS Number assigments. Until then RIPE-525 remains in effect as is. 2) We limited the number of AS Number assignments per LIR to one thousand. This currently values an AS Number assignment at roughly 2 euros, which in my opinion would be a fine number. This approach would have both an abuse-dampening and a garbage collection effect. Thoughts? Kind regards, Job From ebais at a2b-internet.com Sat Aug 16 17:36:46 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Aug 2014 17:36:46 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816143419.GD50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> Message-ID: <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> Hi Job, Policy can't set a price or affect the cost to a resource, as that is decided by the membership in the AGM. I would rather have the NCC monitor the situation and report on it during the NCC services update on the RIPE meetings as they are also doing on the PI IPv6 without multihoming. If the situation would show abusive behaviour from people, the need is there to associate a cost per AS object and you would get it much easier through the AGM ... I would not recommend writing a policy that would only be implemented after a cost decision. And by writing that the Currently policy must stay as is, also doesn't leave an option to make other adjustments.. May I suggest the policy change that was discussed to be able to transfer an ASn. Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 16 aug. 2014 om 16:34 heeft Job Snijders het volgende geschreven: > >> On Sat, Aug 16, 2014 at 03:50:56PM +0200, Gert Doering wrote: >>> On Sat, Aug 16, 2014 at 04:33:57PM +0300, Saku Ytti wrote: >>> I personally would want to see YRC implemented, 1EUR/year/resource, >>> 4294967296 EUR annual revenue will make it possible to finance >>> sufficient long AS number for Nick's use cases. >> >> Unfortunately, APWG has no formal say in this, as everything related >> to money is for the members to decide, and it seems sufficient LIRs >> wanted "no extra costs for AS numbers!" to lobby for the removal >> from the charging scheme... (we had "50 EUR per AS/year" in it) >> >> One would need to personally propose this to the board so they can include >> it in the new charging scheme drafts, *and* get enough members to actually >> vote for it... > > As author I wholeheartedly agree with the two main concerns Nick raises, > we described this concern in the Rationale section B. > > Going forward I see two possible paths, and would appreciate feedback on > either. > > 1) We add a clause to the policy that the policy only takes effect if > either in 2014 or 2015, a yearly recurring cost is associated with AS > Number assigments. Until then RIPE-525 remains in effect as is. > > 2) We limited the number of AS Number assignments per LIR to one > thousand. This currently values an AS Number assignment at roughly 2 > euros, which in my opinion would be a fine number. This approach would > have both an abuse-dampening and a garbage collection effect. > > Thoughts? > > Kind regards, > > Job > From job at instituut.net Sat Aug 16 17:46:34 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 17:46:34 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> Message-ID: <20140816154634.GE50101@pc154.home> On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote: > Policy can't set a price or affect the cost to a resource, as that is > decided by the membership in the AGM. Yes I know, hence my presenting of these two paths forward. > I would rather have the NCC monitor the situation and report on it > during the NCC services update on the RIPE meetings as they are also > doing on the PI IPv6 without multihoming. If the situation would show > abusive behaviour from people, the need is there to associate a cost > per AS object and you would get it much easier through the AGM ... > > I would not recommend writing a policy that would only be implemented > after a cost decision. And by writing that the Currently policy must > stay as is, also doesn't leave an option to make other adjustments.. Noted. > May I suggest the policy change that was discussed to be able to > transfer an ASn. Do you have an URL? What about the option 2, to limit the amount of AS assignments per LIR to 1000? As far as I understand option would fall within APWG's mandate and address the raised concerns. Kind regards, Job From richih.mailinglist at gmail.com Sat Aug 16 17:59:04 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 16 Aug 2014 17:59:04 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816143419.GD50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> Message-ID: On Sat, Aug 16, 2014 at 4:34 PM, Job Snijders wrote: > 2) We limited the number of AS Number assignments per LIR to one > thousand. This currently values an AS Number assignment at roughly 2 > euros, which in my opinion would be a fine number. This approach would > have both an abuse-dampening and a garbage collection effect. I do agree with the aim of the proposal and while I don't see the same potential for abuse as Nick does, mainly because I see no real use or value in having a myriad of ASNs just lying around. Reinstating the 50?/year scheme may make sense, here. As to the option above, at first glance 1000 seems like a lot, but without supporting data, it's hard to tell. Requiring, and verifying, documentation after X ASN may be an option, but this feels like a bandaid where the simple fee used to be. Richard PS: For Gert's benefit: I support this proposal in its current form already, even though there's still room for improvement. From ebais at a2b-internet.com Sat Aug 16 18:07:24 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Aug 2014 18:07:24 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816154634.GE50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> Message-ID: > What about the option 2, to limit the amount of AS assignments per > LIR to 1000? As far as I understand option would fall within APWG's > mandate and address the raised concerns. So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ... Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ... And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ? You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ? Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ? Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 16 aug. 2014 om 17:46 heeft Job Snijders het volgende geschreven: > >> On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote: >> >> Policy can't set a price or affect the cost to a resource, as that is >> decided by the membership in the AGM. > > Yes I know, hence my presenting of these two paths forward. > >> I would rather have the NCC monitor the situation and report on it >> during the NCC services update on the RIPE meetings as they are also >> doing on the PI IPv6 without multihoming. If the situation would show >> abusive behaviour from people, the need is there to associate a cost >> per AS object and you would get it much easier through the AGM ... >> >> I would not recommend writing a policy that would only be implemented >> after a cost decision. And by writing that the Currently policy must >> stay as is, also doesn't leave an option to make other adjustments.. > > Noted. > >> May I suggest the policy change that was discussed to be able to >> transfer an ASn. > > Do you have an URL? > > What about the option 2, to limit the amount of AS assignments per > LIR to 1000? As far as I understand option would fall within APWG's > mandate and address the raised concerns. > > Kind regards, > > Job From job at instituut.net Sat Aug 16 18:39:49 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 18:39:49 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> Message-ID: <20140816163949.GG50101@pc154.home> On Sat, Aug 16, 2014 at 06:07:24PM +0200, Erik Bais wrote: > > What about the option 2, to limit the amount of AS assignments per > > LIR to 1000? As far as I understand option would fall within APWG's > > mandate and address the raised concerns. > > So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Yes, looks like correct math to me. :-) > Not that I want that many, but I'm thinking that the number might be a > bit too big. How many ASn's do you expect is regular use within an LIR Our fear was one LIR consuming all of the remaining ASNs (4.200.000.000 or so?), this is what I try to address. > ... I know personally 1 company that hold 99 AS numbers ( legacy ) and > they actual use is probably less than 30 active AS nr's .. They > received it from IANA back in the days in order to hand them out to > customers ... They might not be the only one ... That does not bother me. > Yes doing a max number per LIR would be within the APwg mandate, but > let's keep things practical ... OK! > And what if you would register an AS within a LIR as an end-user > assign AS, would that could ? Or only the LIR infra structure AS > numbers ? Can you please rephrase the above paragraph? I don't follow. > You may want to ask Andrea as he might know what the current number is > ( max) hold within an LIR ( not including Legacy assigned AS numbers) > ... Personally I don't think it will be a lot that have more 5 AS'n in > their LIR ( especially for their own Infra) .. There might be some > that have a list of AS's requested for end-users. I know I have ... > But if a customer doesn't require an AS number, why would one request > an AS number if the customer doesn't understand what BGP is or if they > don't intend to run BGP ? That is entirely up to these LIRs. The purpose of the policy proposal is to make it easier to obtain an ASN, yet at the same time prevent abusing the liberty the policy could provide. Obtaining AS numbers should be simple for both the very large LIRs and the small LIRs. Setting limit to 5 or even 100 would directly lead to issues for some companies. > Which might actually be the better question in this discussion to ask > instead of asking if you are going to multihome ... Are you going to > run BGP ? And if you are, have you considered a private AS to use > instead of a unique AS number .. Which basically covers everything > that the NCC should know ... Or am I missing something ? Private ASNs are not of any concern to the RIPE NCC. Would be the same as asking for a /29 or /48 IPv6 and being asked "Have you considered using ULA Space?". The answer always is "No, I need a globally unique integer, otherwise I would not go to RIPE NCC for resources" Currently there are 10.692 LIRs, this means a policy proposal (following path 2), could lay claim to 10.692.000 ASNs, iff all LIRS would request the maximum. That unlikely scenario would lead to ~ 0.002% of available ASNs being consumed. I am certain only a very small subset of LIRs will need more than a handful AS number assignments. And in the awkward scenario where some organisation launches a 2000 new LIRs, this would decrease LIR membership fee for everybody significantly, yet still pose no real risk to all ASNs being consumed. Kind regards, Job From nick at inex.ie Sat Aug 16 19:45:15 2014 From: nick at inex.ie (Nick Hilliard) Date: Sat, 16 Aug 2014 18:45:15 +0100 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816143419.GD50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> Message-ID: <53EF98AB.4020101@inex.ie> On 16/08/2014 15:34, Job Snijders wrote: > Going forward I see two possible paths, and would appreciate feedback > on either. > > 1) We add a clause to the policy that the policy only takes effect if > either in 2014 or 2015, a yearly recurring cost is associated with AS > Number assigments. Until then RIPE-525 remains in effect as is. It would be better to bring this up as an agenda item at the next NCC GM and get this problem fixed rather than putting conditionals into the policy. > 2) We limited the number of AS Number assignments per LIR to one > thousand. Please let's not create policy by application of comfortingly round numbers. Nick From ebais at a2b-internet.com Sat Aug 16 19:49:11 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Aug 2014 19:49:11 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816163949.GG50101@pc154.home> References: <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> <20140816163949.GG50101@pc154.home> Message-ID: <29A0F375-A607-4475-84B6-D464CDFAD21A@a2b-internet.com> >> And what if you would register an AS within a LIR as an end-user >> assign AS, would that could ? Or only the LIR infra structure AS >> numbers ? > > Can you please rephrase the above paragraph? I don't follow. Lets try that again, freaking auto-correct and thick fingers.. So, what if you would request ASn's for end-users as a sponsoring LIR, would that count ? Or would only the own infra AS numbers count within an LIR .. > Private ASNs are not of any concern to the RIPE NCC. Would be the same > as asking for a /29 or /48 IPv6 and being asked "Have you considered > using ULA Space?". The answer always is "No, I need a globally unique > integer, otherwise I would not go to RIPE NCC for resources" True, but that was also the question when requesting IPv4. (Rfc1918 space) There might be more to it than an open door. Some people are actually requesting resources without looking at the private use options.. Erik Verstuurd vanaf mijn iPad > Op 16 aug. 2014 om 18:39 heeft Job Snijders het volgende geschreven: > > On Sat, Aug 16, 2014 at 06:07:24PM +0200, Erik Bais wrote: >>> What about the option 2, to limit the amount of AS assignments per >>> LIR to 1000? As far as I understand option would fall within APWG's >>> mandate and address the raised concerns. >> >> So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? > > Yes, looks like correct math to me. :-) > >> Not that I want that many, but I'm thinking that the number might be a >> bit too big. How many ASn's do you expect is regular use within an LIR > > Our fear was one LIR consuming all of the remaining ASNs (4.200.000.000 or > so?), this is what I try to address. > >> ... I know personally 1 company that hold 99 AS numbers ( legacy ) and >> they actual use is probably less than 30 active AS nr's .. They >> received it from IANA back in the days in order to hand them out to >> customers ... They might not be the only one ... > > That does not bother me. > >> Yes doing a max number per LIR would be within the APwg mandate, but >> let's keep things practical ... > > OK! > >> And what if you would register an AS within a LIR as an end-user >> assign AS, would that could ? Or only the LIR infra structure AS >> numbers ? > > Can you please rephrase the above paragraph? I don't follow. > >> You may want to ask Andrea as he might know what the current number is >> ( max) hold within an LIR ( not including Legacy assigned AS numbers) >> ... Personally I don't think it will be a lot that have more 5 AS'n in >> their LIR ( especially for their own Infra) .. There might be some >> that have a list of AS's requested for end-users. I know I have ... >> But if a customer doesn't require an AS number, why would one request >> an AS number if the customer doesn't understand what BGP is or if they >> don't intend to run BGP ? > > That is entirely up to these LIRs. The purpose of the policy proposal is > to make it easier to obtain an ASN, yet at the same time prevent abusing > the liberty the policy could provide. Obtaining AS numbers should be > simple for both the very large LIRs and the small LIRs. Setting limit to > 5 or even 100 would directly lead to issues for some companies. > >> Which might actually be the better question in this discussion to ask >> instead of asking if you are going to multihome ... Are you going to >> run BGP ? And if you are, have you considered a private AS to use >> instead of a unique AS number .. Which basically covers everything >> that the NCC should know ... Or am I missing something ? > > Private ASNs are not of any concern to the RIPE NCC. Would be the same > as asking for a /29 or /48 IPv6 and being asked "Have you considered > using ULA Space?". The answer always is "No, I need a globally unique > integer, otherwise I would not go to RIPE NCC for resources" > > Currently there are 10.692 LIRs, this means a policy proposal (following > path 2), could lay claim to 10.692.000 ASNs, iff all LIRS would request > the maximum. That unlikely scenario would lead to ~ 0.002% of available > ASNs being consumed. > > I am certain only a very small subset of LIRs will need more than a > handful AS number assignments. And in the awkward scenario where some > organisation launches a 2000 new LIRs, this would decrease LIR > membership fee for everybody significantly, yet still pose no real risk > to all ASNs being consumed. > > Kind regards, > > Job From saku at ytti.fi Sat Aug 16 19:53:16 2014 From: saku at ytti.fi (Saku Ytti) Date: Sat, 16 Aug 2014 20:53:16 +0300 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <53EF98AB.4020101@inex.ie> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <53EF98AB.4020101@inex.ie> Message-ID: On 16 August 2014 20:45, Nick Hilliard wrote: > It would be better to bring this up as an agenda item at the next NCC GM > and get this problem fixed rather than putting conditionals into the policy. > >> 2) We limited the number of AS Number assignments per LIR to one >> thousand. > > Please let's not create policy by application of comfortingly round numbers. I agree, the policy is (and should) be simple and without contrived complexity to fix real issue in wrong place. The abuse potential is in current policy as well. so it should not factor in here either, they can be tackled separately, but I definitely support tackling the problem. It is such a simple, elegant and obvious way to manage finite resources, put non-zero cost to them. It fixes other complex problems as well, not just arbitrary policy abuse. -- ++ytti From job at instituut.net Sat Aug 16 20:52:02 2014 From: job at instituut.net (Job Snijders) Date: Sat, 16 Aug 2014 20:52:02 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <29A0F375-A607-4475-84B6-D464CDFAD21A@a2b-internet.com> References: <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> <20140816163949.GG50101@pc154.home> <29A0F375-A607-4475-84B6-D464CDFAD21A@a2b-internet.com> Message-ID: <20140816185202.GH50101@pc154.home> On Sat, Aug 16, 2014 at 07:49:11PM +0200, Erik Bais wrote: > So, what if you would request ASn's for end-users as a sponsoring LIR, > would that count ? Or would only the own infra AS numbers count > within an LIR .. To me they are all just integers, any difference is academic at best. Kind regards, Job From marty at akamai.com Sat Aug 16 23:08:08 2014 From: marty at akamai.com (Hannigan, Martin) Date: Sat, 16 Aug 2014 17:08:08 -0400 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <20140816113124.GA50101@pc154.home> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> Message-ID: With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough. Best, -M< On Aug 16, 2014, at 7:31 AM, Job Snijders wrote: > Dear all, > > Based on the feedback from the working group we have developed a > new iteration of the proposal. > > Concerns addressed: > > - remove private AS Number reference (Fredy Kuenzler, 1 May 2014; Alex > le Heux, offlist; Erik Bais, offlist) > - differentiate between 16 and 32 bit ASN (Nick Hilliard, 1 May 2014; > Aleksi Suhonen, 14 August 2014; RIPE NCC Impact analysis section B > "Autonomous System Number (ASN) Consumption") > - Specify timeline when multihoming is required (Janos Zsako, 11 Jul 2014 > > What has not been addressed is the creation of an exhaustive list of > acceptable reasons to request an ASN. The authors do not know how to > update (without full PDP process) the list when new technologies or > methodologies arise. Rather, the authors believe that RIPE NCC is > responsible for maintaining an accurate registry than evaluate network > designs. In a years time the RIPE NCC could publish an aggregated report > on the recorded needs, possibly to inspire the community to reconsider > this policy. > > ----------------- replaces section 2.0 from RIPE-525 ----------------- > 2.0 Assignment Criteria > > A new AS Number should only be assigned when the End User expresses a need > that cannot be satisfied with an existing AS Number. RIPE NCC will record, > but not evaluate this need. > > When requesting a 16 bit AS Number, the network must be multihomed using > the assigned AS Number within 6 months. A 32 bit AS Number is exempt from > the multihoming requirement. > > When requesting an AS Number, the routing policy of the Autonomous System > must be provided. The new unique routing policy should be defined in RPSL > language, as used in the RIPE Database. > > The RIPE NCC will assign the AS Number directly to the End User upon a > request properly submitted to the RIPE NCC either directly or through a > sponsoring LIR. AS Number assignments are subject to the policies described > in the RIPE Document ?Contractual Requirements for Provider Independent > Resource Holders in the RIPE NCC Service Region?. > ------------------------------------------------------------------------ > > Kind regards, > > Job & Ytti > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From saku at ytti.fi Sat Aug 16 23:25:18 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 17 Aug 2014 00:25:18 +0300 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> Message-ID: On 17 August 2014 00:08, Hannigan, Martin wrote: > With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough. 16b are scarce and special, and one application where you really want to have 16b ASN is when you have >1 upstream and >0 downstream, then you really want to support TE via communities, and for this you are in competitive disadvantage without 16b ASN. Otherwise agreed. -- ++ytti From stolpe at resilans.se Mon Aug 18 15:16:31 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 18 Aug 2014 15:16:31 +0200 (CEST) Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> Message-ID: On Sat, 16 Aug 2014, Erik Bais wrote: >> What about the option 2, to limit the amount of AS assignments per >> LIR to 1000? As far as I understand option would fall within APWG's >> mandate and address the raised concerns. > > So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ... > > Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ... > > And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ? Yes, I think that would be two completly different things. We have a few dozen ASn's tied to a single LIR, most of wich are used by different end users. But as we regularly apply for new ASn's on behalf of end users I am a bit confused here. The suggestion is to take away the multi homing requirement, right? But today, you always get a lot of questions from the NCC if you apply for a second ASn for the same end user. It is not like you will easily get millions of ASn's today just because you can come up with new combinations of 'two peerings'. I might be missing something though. And yes, I would have liked the annual ASn fee to stay. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From nigel at titley.com Mon Aug 18 17:25:37 2014 From: nigel at titley.com (Nigel Titley) Date: Mon, 18 Aug 2014 16:25:37 +0100 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: <53EF98AB.4020101@inex.ie> References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <53EF98AB.4020101@inex.ie> Message-ID: <53F21AF1.8070306@titley.com> On 16/08/14 18:45, Nick Hilliard wrote: > On 16/08/2014 15:34, Job Snijders wrote: >> Going forward I see two possible paths, and would appreciate feedback >> on either. >> >> 1) We add a clause to the policy that the policy only takes effect if >> either in 2014 or 2015, a yearly recurring cost is associated with AS >> Number assigments. Until then RIPE-525 remains in effect as is. > It would be better to bring this up as an agenda item at the next NCC GM > and get this problem fixed rather than putting conditionals into the policy. > And the board has noted your request... we'll discuss at the next board meeting which is in early September. All the best Nigel From dr at cluenet.de Mon Aug 18 18:26:50 2014 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 18 Aug 2014 18:26:50 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> Message-ID: <20140818162650.GA16869@srv03.cluenet.de> On Sun, Aug 17, 2014 at 12:25:18AM +0300, Saku Ytti wrote: > > With "the cloud" allowing for effective single homing these days, do we really need to codify any sort of multi-homing requirement? I also don't see the utility of a list of reasons that someone can be assigned an ASN. Isn't "I'm connecting to a network and speaking bgp" good enough. > > 16b are scarce and special, and one application where you really want > to have 16b ASN is when you have >1 upstream and >0 downstream, then > you really want to support TE via communities, and for this you are in > competitive disadvantage without 16b ASN. The need for TE communities may already exist with multihoming to a single upstream AS. E.g. TE comms to modify localpref to make a link strict-backup in multihoming-to-single-upstream situations. Think 702:[789] Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mschmidt at ripe.net Tue Aug 19 10:44:37 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 19 Aug 2014 10:44:37 +0200 Subject: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement In-Reply-To: References: <20140711082317.B6B9156DC@mail.axu.tm> <53EC26BC.2040506@ssd.axu.tm> <20140816113124.GA50101@pc154.home> <53EF4A04.7060002@inex.ie> <20140816122229.GB50101@pc154.home> <20140816135056.GZ51793@Space.Net> <20140816143419.GD50101@pc154.home> <00BDA08F-D21A-4F93-997A-2EF24CE29493@a2b-internet.com> <20140816154634.GE50101@pc154.home> Message-ID: <53F30E75.7020707@ripe.net> Dear Erik and colleagues, We would like to provide you with some numbers. In the RIPE NCC service region, there are currently 10,874 ASNs assigned to LIRs and 14,181 ASNs assigned to End Users with approved documents. There are 26 organisations (including six with legacy ASNs) with more than ten ASNs registered. The maximum number of ASNs assigned to one organization is 100 (not including legacy ASNs). We hope that this is helps your discussion. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 16/08/14 18:07, Erik Bais wrote: >> What about the option 2, to limit the amount of AS assignments per >> LIR to 1000? As far as I understand option would fall within APWG's >> mandate and address the raised concerns. > So I need 2 lir's to request 2000 ASn's ? And 3 LIR's for 3000 ASn's ? Not that I want that many, but I'm thinking that the number might be a bit too big. How many ASn's do you expect is regular use within an LIR ... I know personally 1 company that hold 99 AS numbers ( legacy ) and they actual use is probably less than 30 active AS nr's .. They received it from IANA back in the days in order to hand them out to customers ... They might not be the only one ... > > Yes doing a max number per LIR would be within the APwg mandate, but let's keep things practical ... > > And what if you would register an AS within a LIR as an end-user assign AS, would that could ? Or only the LIR infra structure AS numbers ? > > You may want to ask Andrea as he might know what the current number is ( max) hold within an LIR ( not including Legacy assigned AS numbers) ... Personally I don't think it will be a lot that have more 5 AS'n in their LIR ( especially for their own Infra) .. There might be some that have a list of AS's requested for end-users. I know I have ... > But if a customer doesn't require an AS number, why would one request an AS number if the customer doesn't understand what BGP is or if they don't intend to run BGP ? > > Which might actually be the better question in this discussion to ask instead of asking if you are going to multihome ... Are you going to run BGP ? And if you are, have you considered a private AS to use instead of a unique AS number .. Which basically covers everything that the NCC should know ... Or am I missing something ? > > Regards, > Erik Bais > > Verstuurd vanaf mijn iPad > >> Op 16 aug. 2014 om 17:46 heeft Job Snijders het volgende geschreven: >> >>> On Sat, Aug 16, 2014 at 05:36:46PM +0200, Erik Bais wrote: >>> >>> Policy can't set a price or affect the cost to a resource, as that is >>> decided by the membership in the AGM. >> Yes I know, hence my presenting of these two paths forward. >> >>> I would rather have the NCC monitor the situation and report on it >>> during the NCC services update on the RIPE meetings as they are also >>> doing on the PI IPv6 without multihoming. If the situation would show >>> abusive behaviour from people, the need is there to associate a cost >>> per AS object and you would get it much easier through the AGM ... >>> >>> I would not recommend writing a policy that would only be implemented >>> after a cost decision. And by writing that the Currently policy must >>> stay as is, also doesn't leave an option to make other adjustments.. >> Noted. >> >>> May I suggest the policy change that was discussed to be able to >>> transfer an ASn. >> Do you have an URL? >> >> What about the option 2, to limit the amount of AS assignments per >> LIR to 1000? As far as I understand option would fall within APWG's >> mandate and address the raised concerns. >> >> Kind regards, >> >> Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Aug 25 20:44:31 2014 From: gert at space.net (Gert Doering) Date: Mon, 25 Aug 2014 20:44:31 +0200 Subject: [address-policy-wg] Moving "2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer)" to Last Call In-Reply-To: <20140710100351.9B9FF60276@mobil.space.net> References: <20140710100351.9B9FF60276@mobil.space.net> Message-ID: <20140825184431.GA15234@Space.Net> Dear Address Policy WG, On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2014-02, > "Allow IPv4 PI transfer" has been published. The impact analysis > that was conducted for this proposal has also been published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 8 August 2014. The review phase for 2014-02 has ended. Given the amount of support, the WG chairs have decided that we have reached consensus. We think that all points brought up by the opposers have been sufficiently discussed - this might not be sufficient to convince the opposers to change their mind, but given sufficient support otherwise, it's good enough to move forward. This is what we'll do now -> move 2014-02 to Last Call. Marco will send the formal announcement for that tomorrow or Wednesday. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what the chairs based their decision on. If you disagree with our interpretation of what has been said, and the conclusion we have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase, starting July 10, 2014 Support: Tore Anderson Sonderegger Olaf Andre Keller Scott Leibrand Elvis Velea Donal Cunningham Juan P. Cerezo Daniel Suchy Piotr.Strzyzewski Larisa Yurkina Hamed Shafaghi Questions: George Giannousopoulos (neutral) Opposing: Aleksei Ivanov (LeaderTelecom), main reason seems to be pricing some discussion, after clarification that APWG cannot directly influence pricing, opposition wasn't kept up In Discussion with Alexsei, without voicing a clear pro/contra statement, mainly about pricing for LIR account, PI, ... Erik Bais Andrzej Dopiera??a Andrei Kushnireuski Jens Ott -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Mon Aug 25 20:47:53 2014 From: gert at space.net (Gert Doering) Date: Mon, 25 Aug 2014 20:47:53 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20140731114101.2BC3D6087A@mobil.space.net> References: <20140731114101.2BC3D6087A@mobil.space.net> Message-ID: <20140825184753.GA15964@Space.Net> Dear Address Policy WG, while I can understand that beaches and drinks are more attractive than policy work, we have a proposal here that needs a bit of caring - this one is in Review Phase until Friday, and has received exactly one comment yet (strong support). I could use a *bit* more feedback here... thanks, Gert Doering, Address Policy WG Chair On Thu, Jul 31, 2014 at 01:30:43PM +0200, Marco Schmidt wrote: > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2014-04, > "Relaxing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. > > Some of the differences from version 1.0 include: > > - Extending the fulfilment of the IPv6 requirement to include any > globally routable unicast IPv6 address block > - Related wording adjustments in the summary and rationale of the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-04 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-04/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 August 2014. > > Regards > > Marco Schmidt > 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Mon Aug 25 20:49:32 2014 From: gert at space.net (Gert Doering) Date: Mon, 25 Aug 2014 20:49:32 +0200 Subject: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <20140711082253.29C1C60174@mobil.space.net> References: <20140711082253.29C1C60174@mobil.space.net> Message-ID: <20140825184932.GB15964@Space.Net> Dear Address Policy WG, another one, and then it's enough for today... On Fri, Jul 11, 2014 at 10:21:11AM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2014-03, > "Remove Multihoming Requirement for AS Number Assignments" has been > published. The impact analysis that was conducted for this proposal > has also been published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 11 August 2014. the review phase is over. Based on the comments received, the authors have decided to work on the text and a "version 2.0" of the document will come forward soon -> new impact analysis and a new round of discussion phase. Stay tuned :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nick at inex.ie Mon Aug 25 21:10:53 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 25 Aug 2014 20:10:53 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20140825184753.GA15964@Space.Net> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> Message-ID: <53FB8A3D.9050403@inex.ie> On 25/08/2014 19:47, Gert Doering wrote: > while I can understand that beaches and drinks are more attractive than > policy work, we have a proposal here that needs a bit of caring - > this one is in Review Phase until Friday, and has received exactly one > comment yet (strong support). I could use a *bit* more feedback here... tl;dr: don't support as-is, but could be convinced -- I support the idea as it's a bugfix policy proposal, but the wording is need to be improved. At the moment, it ties the policy to the idea of the RIPE NCC being the routing police. Probably this isn't the intention. It may be better to consider alternative wording, e.g. > An allocation will only be made to a LIR if the LIR has already been > assigned or allocated an IPv6 address block from a RIR. Even better, remove the requirement completely as it's pointless. Nick From frettled at gmail.com Mon Aug 25 23:59:31 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 25 Aug 2014 23:59:31 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53FB8A3D.9050403@inex.ie> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> Message-ID: On Mon, Aug 25, 2014 at 9:10 PM, Nick Hilliard wrote: > On 25/08/2014 19:47, Gert Doering wrote: > > while I can understand that beaches and drinks are more attractive than > > policy work, we have a proposal here that needs a bit of caring - > > this one is in Review Phase until Friday, and has received exactly one > > comment yet (strong support). I could use a *bit* more feedback here... > Whoops, sorry about that! Beach-and-drink time was over a month ago! > > tl;dr: don't support as-is, but could be convinced > > -- > > I support the idea as it's a bugfix policy proposal, but the wording is > need to be improved. At the moment, it ties the policy to the idea of the > RIPE NCC being the routing police. Probably this isn't the intention. > I think you're right about that. > > It may be better to consider alternative wording, e.g. > > > An allocation will only be made to a LIR if the LIR has already been > > assigned or allocated an IPv6 address block from a RIR. > > Even better, remove the requirement completely as it's pointless. I'm not convinced that it's a pointless requirement, but I concur that the wording needs to be changed a bit before I feel comfortable with it. As it is, however, I don't feel strongly either way about this part of the policy, but a clearer policy is something I'll support. :) -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Tue Aug 26 02:22:42 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 25 Aug 2014 17:22:42 -0700 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> Message-ID: <53FBD352.6090602@v4escrow.net> Hi, On 25/08/14 14:59, Jan Ingvoldstad wrote: > On Mon, Aug 25, 2014 at 9:10 PM, Nick Hilliard > wrote: > > On 25/08/2014 19:47, Gert Doering wrote: > > while I can understand that beaches and drinks are more > attractive than > > policy work, we have a proposal here that needs a bit of caring - > > this one is in Review Phase until Friday, and has received > exactly one > > comment yet (strong support). I could use a *bit* more feedback > here... > > > Whoops, sorry about that! > > Beach-and-drink time was over a month ago! some are still at the beach :) > > > tl;dr: don't support as-is, but could be convinced > > -- > > I support the idea as it's a bugfix policy proposal, but the > wording is > need to be improved. At the moment, it ties the policy to the > idea of the > RIPE NCC being the routing police. Probably this isn't the intention. > > > I think you're right about that. I would go as far as to say, as long as you have/use IPv6 (no matter which color and from whom) you can request the last /22. I would also accept a change proposal that would completely remove this requirement and believe it's even a better idea. > > > It may be better to consider alternative wording, e.g. > > > An allocation will only be made to a LIR if the LIR has already been > > assigned or allocated an IPv6 address block from a RIR. > > Even better, remove the requirement completely as it's pointless. > +1 > > I'm not convinced that it's a pointless requirement, but I concur that > the wording needs to be changed a bit before I feel comfortable with it. > > As it is, however, I don't feel strongly either way about this part of > the policy, but a clearer policy is something I'll support. :) > -- > Jan Kind regards, Elvis -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From andreas.vogler at geneon.de Tue Aug 26 09:02:49 2014 From: andreas.vogler at geneon.de (Andreas Vogler) Date: Tue, 26 Aug 2014 09:02:49 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20140825184753.GA15964@Space.Net> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> Message-ID: <27CE2179D1925A4F9F4874725C3B4E0FB4D4849545@COSMOS.nbg.geneon.de> Hi, I support the proposal. The intention of theIPv6 requirement is to foster IPv6 adoption and the proposed change keeps up this intention. The requirement for IPv6 shouldn't be dropped altogether but relaxing it a bit is Ok. Andreas Vogler IT-Leiter, Prokurist Geneon GmbH I Gutenstetter Str. 8a I 90449 N?rnberg I Entwicklungszentrum Berlin I L?westr. 25 I 10249 Berlin I Tel.: +49 (0)911 36 78 88-21 I Fax: +49 (0)911 36 78 88-20 I Gesch?ftsf?hrer: Yong-Harry Steiert I Registergericht N?rnberg HRB 17193 I USt-IdNr.: DE207317266 I E-Mail: andreas.vogler at geneon.de I www.geneon.de Ein Unternehmen der Willmy MediaGroup >>> www.willmy.de -----Urspr?ngliche Nachricht----- Von: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Gert Doering Gesendet: Montag, 25. August 2014 20:48 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) Dear Address Policy WG, while I can understand that beaches and drinks are more attractive than policy work, we have a proposal here that needs a bit of caring - this one is in Review Phase until Friday, and has received exactly one comment yet (strong support). I could use a *bit* more feedback here... thanks, Gert Doering, Address Policy WG Chair On Thu, Jul 31, 2014 at 01:30:43PM +0200, Marco Schmidt wrote: > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2014-04, > "Relaxing IPv6 Requirement for Receiving Space from the Final /8", has > now been published, along with an impact analysis conducted by > the RIPE NCC. > > Some of the differences from version 1.0 include: > > - Extending the fulfilment of the IPv6 requirement to include any > globally routable unicast IPv6 address block > - Related wording adjustments in the summary and rationale of the > proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-04 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-04/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 29 August 2014. > > Regards > > Marco Schmidt > 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 (0)89/32356-444 USt-IdNr.: DE813185279 From stolpe at resilans.se Tue Aug 26 09:35:22 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 26 Aug 2014 09:35:22 +0200 (CEST) Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53FBD352.6090602@v4escrow.net> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <53FBD352.6090602@v4escrow.net> Message-ID: I mostly agree with Elvis. On Mon, 25 Aug 2014, Elvis Daniel Velea wrote: > Hi, > > On 25/08/14 14:59, Jan Ingvoldstad wrote: >> On Mon, Aug 25, 2014 at 9:10 PM, Nick Hilliard > > wrote: >> >> On 25/08/2014 19:47, Gert Doering wrote: >> > while I can understand that beaches and drinks are more >> attractive than >> > policy work, we have a proposal here that needs a bit of caring - >> > this one is in Review Phase until Friday, and has received >> exactly one >> > comment yet (strong support). I could use a *bit* more feedback >> here... >> >> >> Whoops, sorry about that! >> >> Beach-and-drink time was over a month ago! > some are still at the beach :) >> >> >> tl;dr: don't support as-is, but could be convinced >> >> -- >> >> I support the idea as it's a bugfix policy proposal, but the >> wording is >> need to be improved. At the moment, it ties the policy to the >> idea of the >> RIPE NCC being the routing police. Probably this isn't the intention. >> >> >> I think you're right about that. > I would go as far as to say, as long as you have/use IPv6 (no matter which > color and from whom) you can request the last /22. I would also accept a > change proposal that would completely remove this requirement and believe > it's even a better idea. >> >> >> It may be better to consider alternative wording, e.g. >> >> > An allocation will only be made to a LIR if the LIR has already been >> > assigned or allocated an IPv6 address block from a RIR. >> >> Even better, remove the requirement completely as it's pointless. >> > +1 >> >> I'm not convinced that it's a pointless requirement, but I concur that the >> wording needs to be changed a bit before I feel comfortable with it. >> >> As it is, however, I don't feel strongly either way about this part of the >> policy, but a clearer policy is something I'll support. :) >> -- >> Jan > > Kind regards, > Elvis > -- > > > > Elvis Daniel Velea > > > Chief Business Analyst > > Email: elvis at V4Escrow.net > US Phone: +1 (702) 475 5914 > EU Phone: +3 (161) 458 1914 > > Recognised IPv4 Broker/Facilitator in: > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise private information. If you have received this > email in error, please notify the sender immediately and delete the > original.Any other use of this email is strictly prohibited. > > mvh 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 45 094 556741-1193 104 30 Stockholm From dr at cluenet.de Tue Aug 26 10:48:07 2014 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 26 Aug 2014 10:48:07 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <53FB8A3D.9050403@inex.ie> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> Message-ID: <20140826084807.GA4255@srv03.cluenet.de> On Mon, Aug 25, 2014 at 08:10:53PM +0100, Nick Hilliard wrote: > > An allocation will only be made to a LIR if the LIR has already been > > assigned or allocated an IPv6 address block from a RIR. > > Even better, remove the requirement completely as it's pointless. Couln'd agree more. This requirement does nothing for actual IPv6 deployment. It just forces people to fill out another form and pimp statistics. That's what we call "window dressing". If and when people want to deploy IPv6, they will request IP space for this. If they don't, having a net block lying around doesn't make them deploy any sooner. IMHO. YMMV. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mschmidt at ripe.net Tue Aug 26 11:20:52 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 26 Aug 2014 11:20:52 +0200 Subject: [address-policy-wg] 2014-02 Last Call for Comments (Allow IPv4 PI transfer) Message-ID: Dear colleagues, The proposal described in 2014-02, "Allow IPv4 PI transfer", 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 24 September 2014 and must be supported by an explanation. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-02 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 24 September 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC