From martin+apwg at rodecker.nl Mon Jun 3 10:28:49 2019 From: martin+apwg at rodecker.nl (Martin Pels) Date: Mon, 3 Jun 2019 10:28:49 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <8865a84c-1ee4-5237-c135-f18885f2d678@rodecker.nl> Hi Kai, On 29/05/19 16:33, Kai 'wusel' Siering wrote: > The IXPs I've experienced explicitely prohibit announcment (i. e. routing) of their space nor announce it theirselves; so why spend another whole /15 as private address space? Obviously, there is no need for global routabillity, where is the need for global uniqueness and why can't this be solved differently (everyone has to cope with IPv4 scarceness, why can't IXPs)? As the pool of unallocated IPv4 addresses depletes, new IXPs will need to adopt new strategies, just like their customers. There are several downsides of using the same address space in multiple IXPs: - IXP participants will not be able to connect the same router to multiple IXPs. This is something that is done quite a lot, especially by smaller networks that connect via remote peering. - It becomes impossible to identify in traceroutes which IXP was crossed. This makes troubleshooting a lot more complicated. - The consequences of address space leaks are more severe. When a participant of a smaller IXP leaks the peering LAN prefix to the routing table this will cause instability at all IXPs that use a prefix that covers the same block. Kind regards, Martin From andy at nosignal.org Mon Jun 3 19:53:13 2019 From: andy at nosignal.org (Andy Davidson) Date: Mon, 3 Jun 2019 17:53:13 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190531071516.GL25123@Space.Net> Message-ID: <26CF348F-B6DB-493D-8A38-03C442F66BAB@nosignal.org> Dear Wolfgang, all -- ?On 31/05/2019, 08:47, Wolfgang Tremmel wrote: > when an IXP first applies for an allocation out of the pool it has zero customers. I have applied for, or supported a number of assignments in a number of different registries on a number of occasions. One of the very few things that they all had in common is customers. It was always necessary to demonstrate to the registry that the IXP has demand and will support connections right away. This is a healthy qualification that a prospective IXP should have to demonstrate. That said we do agree that IXPs should by default receive the /24. Andy From aris.lambrianidis at ams-ix.net Tue Jun 4 19:03:21 2019 From: aris.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Tue, 4 Jun 2019 19:03:21 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> Message-ID: <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> Consulting the PCH IXP directory as Nick did earlier (as well as the Euro-IX one), I think it is also reasonable to say that allocating a /24 is ambitious for the overwhelming majority of cases. Only 64 of listed IXPs have equal to, or more than, 100 participants, out of 958 IXPs, or about 6.6%. In this light, perhaps the default allocation discussed in 6.1.4 should go down to a /25. Looking at the the other end, it's not clear to me as to why an applicant cannot get more than a /23, if there is strong evidence necessitating it. To throw some random numbers as an example, this could be by demonstrating 70%-80% use of their current pool and submitting projected and historical growth rate data. Lastly, 6.1.2 mentions that "other uses are forbidden". Policies looking to enforce certain conditions are only meaningful if there is a framework for: a) Monitoring policy violations with accompanying documentation describing frequency, methodology etc. b) Describing disciplinary actions Kind regards, Aris From nick at foobar.org Tue Jun 4 20:17:43 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 4 Jun 2019 19:17:43 +0100 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> Message-ID: <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> Aris Lambrianidis wrote on 04/06/2019 18:03: > Consulting the PCH IXP directory as Nick did earlier (as well as the > Euro-IX one), I think it is also reasonable to say that > allocating a /24 is ambitious for the overwhelming majority of cases. > > Only 64 of listed IXPs have equal to, or more than, 100 participants, > out of 958 IXPs, or about 6.6%. > > In this light, perhaps the default allocation discussed in 6.1.4 should > go down to a /25. /25 is too small, even for smaller IXPs. ~400-500 of the entries in the PCH IXP directory are defunct. For the remainder, the participant numbers are inaccurate, mostly on the low side. A figure of about 500 active IXPs is largely corroborated by the IXP DB (650 entries, with some effectively defunct). The figure you need to look at is 50% usage rather than 100% usage. If you pin the assignment size to /25, then 50% of /25 is 64 participants, i.e. about ~20-25% of IXPs, not 6.6%. The current run-out rate for the RIPE pool is about 15k addresses per day. This means that a /16 is 4 days worth of allocations at the current rate. A /16 pool gives adequate breathing room for core internet infrastructure, with a /24 assignment size. The central question of this policy update is not the assignment size for IXPs, but whether it's worth investing 4 days out of 30 years worth of allocations in order to provide important flexibility for the internet core in the future. I'm inclined to think it is. Nick From gert at space.net Tue Jun 4 20:33:13 2019 From: gert at space.net (Gert Doering) Date: Tue, 4 Jun 2019 20:33:13 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> Message-ID: <20190604183313.GA25123@Space.Net> Hi, On Tue, Jun 04, 2019 at 07:03:21PM +0200, Aris Lambrianidis wrote: > Lastly, 6.1.2 mentions that "other uses are forbidden". Policies looking > to enforce certain conditions are > only meaningful if there is a framework for: > a) Monitoring policy violations with accompanying documentation > describing frequency, methodology etc. > b) Describing disciplinary actions Disciplinary actions in address policy violation is fairly much straightforward - if you get a block of addresses that comes with restrictions, and you ignore these even if told to stop doing so, the assignment is void and the address space returns to the RIPE NCC. This is the way all our policy framework is organized - like if a LIR receives an allocation and assigns space from that to their customers, the allocation holder is required to provide correct documentation. If this is not done, and the NCC gets to know about it, they will ask the holder to correct it and this is not happening, the address space will be reclaimed. Now, regarding the "monitoring" bit - since we're all mostly well-behaved here, describing the limitations and requirements upfront and only acting in cases where the NCC is informed about misuse works fairly well in practice (though some people in the anti-abuse community might not agree with me here). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cfriacas at fccn.pt Tue Jun 4 21:57:55 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 4 Jun 2019 20:57:55 +0100 (WEST) Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190604183313.GA25123@Space.Net> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <20190604183313.GA25123@Space.Net> Message-ID: On Tue, 4 Jun 2019, Gert Doering wrote: (...) > Now, regarding the "monitoring" bit - since we're all mostly well-behaved > here, :-))) > describing the limitations and requirements upfront and only acting > in cases where the NCC is informed about misuse works fairly well In this specific case would you call the NCC "the police", or would you classify who informs the NCC as "the police"...? :-) > in > practice (though some people in the anti-abuse community might not agree > with me here). Yes, it seems you are way too optimistic, most of the times... :-))) Cheers, Carlos > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > 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 Ian.Dickinson at tfmnetworks.com Tue Jun 4 22:06:06 2019 From: Ian.Dickinson at tfmnetworks.com (Ian Dickinson) Date: Tue, 4 Jun 2019 20:06:06 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> Message-ID: Nick Hilliard wrote: > The central question of this policy update is not the assignment size for IXPs, but whether it's worth investing 4 days out of 30 years worth of allocations in order to provide important flexibility for the internet core in the future. I'm inclined to think it is. I agree, and I support this policy proposal with a /24 default size. Ian Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Jun 4 22:27:51 2019 From: randy at psg.com (Randy Bush) Date: Tue, 04 Jun 2019 13:27:51 -0700 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <20190604183313.GA25123@Space.Net> Message-ID: > In this specific case would you call the NCC "the police", or would > you classify who informs the NCC as "the police"...? :-) https://de.wikipedia.org/wiki/Das_Leben_der_Anderen From gert at space.net Tue Jun 4 22:47:34 2019 From: gert at space.net (Gert Doering) Date: Tue, 4 Jun 2019 22:47:34 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <20190604183313.GA25123@Space.Net> Message-ID: <20190604204734.GI25123@Space.Net> Hi, On Tue, Jun 04, 2019 at 08:57:55PM +0100, Carlos Fria?as wrote: > On Tue, 4 Jun 2019, Gert Doering wrote: > > (...) > > Now, regarding the "monitoring" bit - since we're all mostly well-behaved > > here, > :-))) > > > describing the limitations and requirements upfront and only acting > > in cases where the NCC is informed about misuse works fairly well > > In this specific case would you call the NCC "the police", or would you > classify who informs the NCC as "the police"...? :-) Neither. The NCC is the registry who gives out addresses under very specific conditions, and if these conditions are not met by the receiving side, the address assignment/allocation is automatically voided. This is a pure contractual thing. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From aris.lambrianidis at ams-ix.net Wed Jun 5 02:49:05 2019 From: aris.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Wed, 5 Jun 2019 02:49:05 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> Message-ID: Nick Hilliard wrote on 04/06/2019 20:17: > /25 is too small, even for smaller IXPs. > > ~400-500 of the entries in the PCH IXP directory are defunct.? For the > remainder, the participant numbers are inaccurate, mostly on the low > side. A figure of about 500 active IXPs is largely corroborated by the > IXP DB (650 entries, with some effectively defunct). Hmm.. why shouldn't defunct IXPs not be taken in consideration though? To me that sounds like ~400-500 IXPs requesting an allocation at some point in time, and probably most of them not needing anything more than a /24 (or maybe less), assuming they failed in their mission. As much as I'd love to assume that all IXPs requesting allocations onwards will succeed (and thus needing more than /25 or /24), I don't think that's realistic. So I still believe averaging participants across all of the IXP entries, be it Euro-IX (probably more accurate), or even PCH, is an acceptable metric. > The central question of this policy update is not the assignment size > for IXPs, but whether it's worth investing 4 days out of 30 years > worth of allocations in order to provide important flexibility for the > internet core in the future.? I'm inclined to think it is. Agreed, and: Marco's email mentions "This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria." IMO fine tuning the initial allocation to a /25 makes sense, if only to further the mission of the policy and extend the life of the pool. If anything, IXPs could always provide evidence as to why they need more IP space, even initially, regardless of whether it's a /24 or a /22. To summarize my point of view, having more stringent controls as to who gets what seems only reasonable, given the scarcity of the resource, but allow for flexibility, if the application is well justified. Kind regards, Aris From nick at foobar.org Wed Jun 5 11:41:28 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 5 Jun 2019 10:41:28 +0100 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> Message-ID: <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Aris Lambrianidis wrote on 05/06/2019 01:49: > Hmm.. why shouldn't defunct IXPs not be taken in consideration though? Because they will have handed back their address space. The address assignment policies are explicitly designed to have a garbage collection mechanism under 2007-01. If you don't actively maintain your registration, it reverts to the registry. Nick From aris.lambrianidis at ams-ix.net Wed Jun 5 11:58:26 2019 From: aris.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Wed, 5 Jun 2019 11:58:26 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Message-ID: > On 5 Jun 2019, at 11:41, Nick Hilliard wrote: > > Because they will have handed back their address space. The address assignment policies are explicitly designed to have a garbage collection mechanism under 2007-01. If you don't actively maintain your registration, it reverts to the registry. > > Nick Sure, but consider this simplified scenario: 1. In June 2019, IXP A requests an allocation. They get a /24. 2. In June 2020, the reserved pool is exhausted. 3. In July 2020, IXP B requests allocation but can't get one due to 2. 4. Sometime in 2021 (or even later), IXP A hands over their allocation. What would IXP B do in the mean time between July 2020 and 2021 (or even later) when IXP A handed back their allocation? Of course another IXP could have handed back their address space, but this doesn't change the point made: Defaulting to a smaller allocation increases the chance (if ever so slightly) that the pool will be exhausted at a later point and thus IXP B will get an allocation in July 2020. On a smaller note, I could also tentatively argue that being able to hand over new allocations is more important to ecosystem diversity than being able to honor requests for increasing existing ones. Kind regards, Aris -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From randy at psg.com Wed Jun 5 12:47:30 2019 From: randy at psg.com (Randy Bush) Date: Wed, 05 Jun 2019 03:47:30 -0700 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Message-ID: >> Hmm.. why shouldn't defunct IXPs not be taken in consideration >> though? > Because they will have handed back their address space. what are you trying to measure? the space utilization of current operating exchanges, or the distribution of request sizes? randy From matthias.wichtlhuber at de-cix.net Fri Jun 7 13:00:43 2019 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Fri, 7 Jun 2019 11:00:43 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Message-ID: Hi, I have compiled an in-depth analysis of peeringdb data. You can find a full description of the method, scripts, data and the main results on github: https://github.com/mwichtlh/address-policy-wg/ Some interesting takeaways: * Roughly 83% of all IXPs would theoretically fit into a /25. This already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At the same time, 74% of all peering LANs are /24s. Consequently, the default policy of assigning /24s has created large amounts of unused space. * Already today, more than 10% of all peering LANs are smaller or equal a /25. Having small peering LANs is not entirely unusual. * Large IXPs requiring a /23 or larger are rare (<3%). Thus, lowering the upper bound for assignments to /23 will not save large amounts of space. Conclusions: I back the proposal except for the limitation to a /23. I propose having a /21 as an upper limit with thorough checks by RIPE. Regards, Matthias On Wed, 2019-06-05 at 03:47 -0700, Randy Bush wrote: > > > Hmm.. why shouldn't defunct IXPs not be taken in consideration > > > though? > > > > Because they will have handed back their address space. > > what are you trying to measure? the space utilization of current > operating exchanges, or the distribution of request sizes? > > randy > -- Dr.-Ing. Matthias Wichtlhuber Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne From tore at fud.no Fri Jun 7 13:48:34 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 7 Jun 2019 13:48:34 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Message-ID: * Matthias Wichtlhuber > I have compiled an in-depth analysis of peeringdb data. You can find a > full description of the method, scripts, data and the main results on > github: > > https://github.com/mwichtlh/address-policy-wg/ Very nice work! Thank you for sharing this! > Some interesting takeaways: > > * Roughly 83% of all IXPs would theoretically fit into a /25. This > already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At > the same time, 74% of all peering LANs are /24s. Consequently, the > default policy of assigning /24s has created large amounts of unused > space. This makes me even more convinced that the default assignment size should not be set at /24, but that the assignment should be right-sized to best match the request - all the way down to the minimum assignment size. Another takeaway: looking at Figure 2 it would appear that more than 40% of IXPs would fit all their members in a /28. There are fragments as small as /29 sitting in NCC inventory. They are currently not allocatable or assignable due to the lack of any policy permitting this. I believe /29 should be minimum assignment size (and not /27 as currently proposed), as IXPs are one of the very few use cases where fragments smaller than /24 are useful. There is no reason to let these fragments rot in the NCC's cellar, if they could possibly be used by an IXP somewhere. (Just here in Norway there are four different IXPs that could make do with a /29 given their current member count: TRDIX, BIX, TIX and SIX. This is not because they are brand new or anything, they just happen to be located in regional locations where there is a limited number of potential members.) For IXPs that are about to grow out of an initial small assignment, swapping it for a larger one is doable (and the smaller they are, the less of a hassle the renumbering operation is). The policy already facilitates this (although it should probably not specify that the replacement is a /23, which the current proposal does). > I back the proposal except for the limitation to a /23. I propose > having a /21 as an upper limit with thorough checks by RIPE. I would not object to that. Tore From randy at psg.com Fri Jun 7 16:35:26 2019 From: randy at psg.com (Randy Bush) Date: Fri, 07 Jun 2019 07:35:26 -0700 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> <5770fa88-6f96-2a8b-efbf-9070bf7b3d5b@ams-ix.net> <84323719-75d5-6cfa-907c-264293ee1800@foobar.org> <9ccc209e-9e4e-9c07-5666-4b7b4781e6f2@foobar.org> Message-ID: > https://github.com/mwichtlh/address-policy-wg/ nice randy From ebais at a2b-internet.com Mon Jun 24 17:18:14 2019 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 24 Jun 2019 15:18:14 +0000 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: <84457617-5134-4099-8231-D0417E2F0402@a2b-internet.com> Dear working group, The review phase has ended and the AP-WG Chairs have declared rough consensus on the feedback received, during the Review Phase. We like to thank Randy, Tore, Christoffer and Peter Hessler for their support and Kai for his remark. ( which was addressed by the author Sander.) Marco, If you could push this into last call, that would be great. On behalf of the AP-WG Chair collective, Erik Bais Co-Chair of AP-WG ?On 06/05/2019, 13:10, "address-policy-wg on behalf of Marco Schmidt" wrote: Dear colleagues, Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC?s free IPv4 pool is exhausted. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - New proposal title - Focus on waiting list requirements - Adjusting the moment of policy activation The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 4 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mschmidt at ripe.net Tue Jun 25 09:47:47 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 25 Jun 2019 09:47:47 +0200 Subject: [address-policy-wg] 2019-02 Last Call for Comments (IPv4 Waiting List Implementation) Message-ID: Dear colleagues, Proposal 2019-02, "IPv4 Waiting List Implementation", is now in Concluding Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC?s free IPv4 pool is exhausted. The WG co-chair has declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made by 24 July 2019 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 Please e-mail any final comments about this proposal to before 24 July 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum